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

Re: [Handle-info] indirect handles actually implemented?



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi Sean,

> a simple, lightweight XML/SGML parser in the client jar

How lightweight is it? :-)

> I think it would make sense to have a separate index
> that allowed for things such as reverse URL lookup.

As said - for me, I only use HS to publish copies of the
information in my separate "normal database", so all the
complicated lookups such as reverse ones or "all handles
where the field AUTHOR contains data X" are done there.
So I have no need for the HS to provide such services...



> I don't think "locatt" could be a replacement for country

That was not what I meant... I meant locatt to get a
manually selected item from the list and "closeto" to
get an item selected by a combination of network or
geographical proximity and load balancing, without a
query method which would differentiate between both.

You can often find the client country from the IP, but
not always, and it is a nice idea in general to give
"closeto" an optional "country as specified by the
client user" argument anyway. Old "mirror tradition",
and allows client and server to use fuzzy geographical
matching and manual overrides. For example the client
could manually inspect the URL list for one handle, see
that a nice mirror for that file exists in Belgium and
then decide that he "lives in Belgium" while in reality
(and according to his IP) he is in the Netherlands. He
could use "closeto:belgium" for the rest of the day :-).



> ... if it used something like OpenURL or URL templates
> in general (with the handle itself as a parameter).

Depends a lot on the balance between expression power
and computational cost for the resolver. I tend towards
zero power and zero cost, just store the exact URLs for
all copies in each handle itself...

> It is really a general mechanism of saying "this object
> lives at repository X" and letting repository X locate
> the object within its own filing system rather than having
> to store a static URL with an http domain + file path in
> every handle.

Ah okay so the repository X would actually get (a transform
of) the Handle as input, not really an URL... Not sure if
that is useful... I mean you could always use normal URL
fields for that and say "a copy of this object exists at
hdl:PREFIX-OF-X/THIS-HANDLE" by setting the URL to the hdl
value rather than having the server compute s.th. like a
template based "URL is http://SERVER-OF-X/SERVICE/[HANDLE]";.

In this example the [] part would be *computed* on the fly
while all other parts are *stored* as data for the handle.
The hdl:... would be an "indirect URL via a handle", using
only lookup, while the "URL is..." would need computation.

Regards, Eric

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIBI7c99dkROyhRRsRAiCBAJ9PtBve89nhfz9N4arsLuagy5C7DQCghWqV
ed8R4pxyBp82ltkvNJS0oRY=
=YFz5
-----END PGP SIGNATURE-----


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