[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Handle-info] HS_VLIST for chaining handles?

Hi Tony,

It seems like what you are describing is something like a "server side include" for handles. No such thing currently exists. Something like this could be implemented as a custom HandleStorage module that replaces, or extends, the database interface in the java implementation of the handle server.

One thing to keep in mind is that server performance will suffer with such a feature because the referenced handle may not exist on the same server, requiring the handle server to exchange multiple network messages with other servers in order to return the values for one handle from its database. In that case caching and reference loops may also become a problem.

I don't see any scalability concerns if the loading of values is done on the client side at the application level. That was the idea behind the HS_ALIAS and HS_VLIST types. In the case of HS_VLIST the the authorization code in the handle server is traversing the HS_VLIST contents. The client software can easily perform "hop counts" when resolving HS_ALIAS values in order to prevent loops. Doing this at the application level also prevents any confusion about which values are actually part of the handle and which are associated with the handle by reference, which is a concern when performing administration on a handle.

Thanks,
Sean

On Apr 30, 2008, at 11:00 , Hammond, Tony wrote:

Hi:

(Never averse to replying to my own questions.)

I just realized after posting this that the HS_VLIST type allows for mixing
in discrete handle values rather than the complete set of values at a given
handle. This is a very useful admin functionality but perhaps more fine
grained than what I was reaching for.

If one wanted to import (or let's just say 'reference" to avoid contention)
all handle values maybe the simplest way would just be to use a type of
'HDL' (or similar). I don't think there is a registered type but then I'm
not sure how to get a listing of all registered types. (Is there a way to
get such a complete listing?)

So, using the terminology of the previous example would something like this

       {
           "index" : "123" ,
           "type" : "HDL" ,
           "data"  : "test/2"
           "permission" : "1110" ,
           "ttl" : "+86400" ,
           "timestamp" : "Sun Nov 25 13:33:30 GMT 2007" ,
           "reference"  : []
       }

be a reasonable approach to importing (or at least, referencing) values from
"hdl:test/2"?

(And apologies for the extraneous "}," in the earlier example.)

Course that also leads to questions about parent/child or master/slave
relationships between two paired handles. I guess, that kind of relationship
could be built in to the typing but may be best to leave it as a simple peer
level relationship with bidirectional references:

   hdl:test/1 -> hdl:test/2
   hdl:test/2 -> hdl:test/1

Cheers,

Tony


On 29/4/08 17:14, "Hammond, Tony" <t.hammond@nature.com> wrote:

Hi:

Is there any recommended way to chain handles together, i.e. to keep two
handles in lockstep? Would this be an appropriate use of the HS_VLIST
predefined type?

Let's say, for sake of argument, that hdl:test/2 was being used to extend
hdl:test/1 value space. Would the simple inclusion of a value (say index 42
of hdl:test/2) in hdl:test/1 as e.g. (here using JSON "compact" syntax which
uses the handle URI querystring form to denote a handle value)

       {
           "index" : "123" ,
           "type" : "HS_VLIST" ,
           "data"  : [ hdl:test/2?index=42 ]
           } ,
           "permission" : "1110" ,
           "ttl" : "+86400" ,
           "timestamp" : "Sun Nov 25 13:33:30 GMT 2007" ,
           "reference"  : []
       }

be sufficient to "lock in" hdl:test/2 and so all values from hdl:test/2 .

Could this be seen as something like an "include" statement wrt values? I
know that the handle specs make no semantic claims (apart from noting that "
HS_VLIST values may be used to define administrator groups for handles") and
that these are merely a collection of pointers. But could that be a
reasonable interpretation? Sort of like an rdfs:seeAlso property?

(Note: In JSON "full" syntax the data element would be expressed more
uncompactly as something like:

"data" : {
"referenceCount" : "1" ,
"referenceList" : [
{ "handle" : "test/2" , "handleValueIndex" : "42" }
]
} ,
)

Cheers,

Tony




_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info