Lockfile location

[Luigi Paioro]

Dear Mark (and All),

reading again your mail here below reported, where you expose your 
doubts about the need of passing the endpoint parameters directly in the 
SAMP_HUB env. variable, I'm now persuaded that actually it is not really 
needed: what can be put in the variable can also be written in a file 
and then passed the lockfile URL. Then, summarising, this might be the 
SAMP_HUB syntax:

    value            ::= lockurl-target
    lockurl-target   ::= "std-lockurl:", url
    url              ::= ? any valid URL ?

So, for example:

    SAMP_HUB=std-lockurl:file:///home/luigi/.samp-1/samp-hub-12019-1

or

    SAMP_HUB=std-lockurl:http://host.domain:8080/data/hubdoc


and that's all. Quite simple and clear.

Thanks in advance to you and all for any comment, opinion, agreements, 
disagreements...


Luigi



> Luigi,
>
> I think this idea is basically a good one, since there are times
> when a custom method of hub discovery can be useful (for instance
> one user running multiple separate hubs at the same time).
> I've found the need to introduce something similar in JSAMP for
> testing purposes (using java system properties), but it would
> certainly be better if this were part of the standard rather
> than a non-standard per-implementation.
>
> Unless anybody presents a good reason why not, I am in favour
> of a proposal like this which allows to specify the lockfile
> from an environment variable.  A possible objection is that
> an environment variable is (unlike the rest of the definition)
> a somewhat OS-dependent concept, but since it's clear what it
> means on both MS Windows and Unix-like systems, I don't think
> that's a serious concern.
>
> I'm less convinced about syntax which allows you to specify the
> XML-RPC endpoint and secret directly.
>
>   - It complicates the syntax.
>
>   - Although the syntax you propose is likely to be fine in practice,
>     I don't think it's watertight; for instance if your secret string
>     contains a comma (or even the substring ",url=") parsing might
>     get confused.  This might mean that conscientious parsing code
>     is complicated.
>
>   - As stated the samp.profile.version is not specified.  As far as
>     I know this isn't actually used by existing software, but it is
>     defined as mandatory in sec 4.3 of SAMP 1.11 REC, so probably
>     it ought to be, otherwise code will lack information it might
>     (in principle) otherwise be relying on (may become more important
>     if we actually introduce later versions).  Of course, the syntax
>     you state can readily be extended to include this version string.
>
>   - This is reinventing syntax to encode the same information that
>     is defined by the lockfile itself, so it's reinventing what
>     sec 4.3 does.
>
>   - Is there a compelling use case?
>
> To avoid doing the same thing twice in the standard, I'd suggest
> a similar but simpler proposal for the content of the SAMP_HUB
> variable:
>
>     value            ::= lockfile-target | other-target
>     lockfile-target  ::= "std-lockfile:" file-path
>     file-path        ::= ? any valid file path ?
>     other-target     ::= ? any other profile dependent string ?
>
> with maybe one or both of the following additions:
>
>     value            ::= lockfile-target | lockurl-target | lockdata-target | other-target
>     lockurl-target   ::= "std-lockurl:" url
>     url              ::= ? any valid URL ?
>     lockdata-target  ::= "std-lockdata:" lockdata
>     lockdata         ::= ? bytes which would form a valid lockfile ?
>
> so for example:
>
>     SAMP_HUB=std-lockfile:/home/luigi/.samp-1/samp-hub-12019-1
>
>     SAMP_HUB=std-lockurl:http://host.domain:8080/data/hubdoc
>
>     SAMP_HUB=std_lockdata:samp.hub.xmlrpc.url=http://127.0.0.1:42866/xmlrpc\nsamp.secret=75fb6691223bb6e6\nsamp.profile.version=1.11
>       (where the '\n' are actual characters 0x0a)
>
> This means that parsing the environment variable is very easy and
> unambiguous.  If the lockdata-possibility is permitted, it's also
> possible to supply endpoint and secret (and version) inline, without
> having to invent any new syntax, since it's re-used from section 4.3.
> This would require inclusion of "\n"/"\r" characters in the value
> of the environment variable; I think that's permissible (though maybe
> a bit unconventional) in Un*x; does anybody know about MS Windows?
>
> I'm happy to hear Luigi's or other people's opinions or disagreements.
>
> Mark