Lockfile location

[Mark Taylor]

On Thu, 1 Apr 2010, Luigi Paioro wrote:

> Dear All,
> 
> this is the first of a couple of e-mails where I'd like to submit at your
> evaluation two proposals of small backward compatible changes/improvements in
> SAMP protocol (which is still at the first REC since almost one year).
> 
> On September 2009 (more or less) we discussed about a possible alternative
> mechanism for a client to reach a Hub respect the present one:
> 
> http://www.ivoa.net/forum/apps-samp/0909/0368.htm
> 
> Mark suggested that the lockfile location could be searched as the value of an
> environment variable if it exists, otherwise falling back to the <home>/.samp
> file as now.
> 
> Following this suggestion I proposed the environment variable having a name an
> a value as specified in this EBNF:
> 
> name     ::= "SAMP_HUB" ;
> 
> value    ::= std | ? any other profile dependent string ? ;
> std      ::= "std:", endpoint ;
> endpoint ::= lockfile | params ;
> lockfile ::= "lockfile=", ? any valid file path ? ;
> params   ::= secret, ",", url ;
> secret   ::= "secret=", ? any string ? ;
> url      ::= "url=", ? any valid URL ? ;
> 
> 
> Examples:
> 
> SAMP_HUB = \
> "std:secret=75fb6691223bb6e6,url=http://127.0.0.1:42866/xmlrpc"
> 
> or
> 
> SAMP_HUB = \
> "std:lockfile=/home/luigi/.samp-1/samp-hub-12019-1"
> 
> 
> the "std:" prefix specifies that the endpoint refers to a Standard Profile
> hub... in principle the environment mechanism can be used with other profiles
> as well, thus a prefix which specifies the profile type might be useful.
> 
> I think that introducing something like the proposal above would be simple,
> backward compatible and rather useful. I would really appreciate any comment
> or opinion on this issue.

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

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/