[MOBY-dev] [moby] Re: RFC #1914 - change & call for vote

[Martin Senger]

> I was also thinking along these lines.  So long as our tooling never
> *shows* the version number to the user (or at least, not unless they ask
> for it), then it really doesn't matter how comlpex the version number
> format is.  I don't know if adding a timestamp is any more complex than
> incrementing a version number... but it might be more informative??
>
   Timestamp can be a number of elapsed second/millisecond from the
beginning of an epoche. So it is a long integer - not that different from
a usual version number. Important is that it is always the same
unless/until the entity is re-registered.
   Incrementing a version number is more complex than timestamp because in
order to increment you need to know an old value (that will be
incremented). With a timestamp you do not need to keep unregistered
objects at all. You need just to add a new column "timestamp" and fill it
with the current time when an object is registered. And to add this
"timestamp" field as version to the created LSID. That seems all you need
to do (but perhaps I am still missing some catch).
 
> I see - so jMoby would not automatically know about any newly registered
> objects unless you explicitly asked for a refresh of the entire RDF;
>
   (Almost) correct. jMoby (its caching mechanism) does not know about any
newly registered objects automatically, the user has to ask for update
(the "user" can be, however, a cron job, or whatever). But for refreshing,
jMoby does not use RDF - but it asks for a list of entities using normal
API call (such as getServiceNames - or whatever the method is called, I
can't remember now). There is no such RDF document to give me "only" a
list of object names (and I am not asking for that, the API is fine).

> however you WOULD be guaranteed of always having the latest version of
> whatever object you were working with, because as soon as you "selected"
> it, that PARTICULAR object would be validated against the registry.  Is
> that correct?
> 
   Yes, it could be done this way. The "selection" can trigger the update
mechanism. But it does not - the users (of dashboard, for example) have to
click on a button 'update' if they feel that their cache is not
up-to-date. This does not seem to be a problem in the real life.

> Do you want to write up an addition to the RFC?
>
   Well, adding a version number to the LSIDs is not really a change that
needs an RFC I guess. It is just making current existing features better -
and without breaking existing software. I would suggest that you just ask
Eddie to add versioning and then you both can announce it as a improved
feature. I would really love it to have - and I can at once make use of it
in Dashboard (and slightly later, and with coordination with Eddie, in
Taverna).
 
> (we still don't know what you want to be returned by a getData call -
> you are keeping us in suspense! ;-) )
> 
   I said: I am stepping back a bit. Talk about getData() brought me to
versioning - and that's what I wish to have. Forget getData() for now :-)
   (Mainly because what I would return by getData() is identical to what
normal old-fashioned moby API calls do quite well now (such as
retrieveObjectDefinition()) ).

   Martin

PS. TW, Mylah from IRRI is just finishing her mirroring scripts (to
regularly update our local/testing GCP registry from the central one) -
and she would definitely welcome the versions as well - mirroring is just
another example (additional to my local caching usage) where LSIDs with
versions would be tremendously and immediately useful. M.

-- 
Martin Senger
   email: martin.senger at gmail.com
   skype: martinsenger
consulting for:
   International Rice Research Institute
   Biometrics and Bioinformatics Unit
   DAPO BOX 7777, Metro Manila
   Philippines, phone: +63-2-580-5600 (ext.2324)