Bug #1883
closed
This is mostly accomplished. The object manager uses LSIDs to identifiy cache
items. Some refactoring is being considered to make the old cache manager aware
of LSIDs. Also need to resolve the issue of using 'localhost' as an LSID
authority because it allows the possibility of conflicting LSIDs.
the objectcache will replace the datacachemanager as the main caching system in
kepler. the objectcache relies completely on LSIDs for unique identification of
objects. The infrastructure for dealing with lsids within kepler is complete.
There is an LSIDGenerator to create local lsids, an LSIDTree to keep track of
uniqueness and the KeplerLSID class itself that wraps the IBM LSID class so that
we can use local lsids.
there is a need for locally assigned lsids. the problem with using localhost as
the authority is that 2 people on 2 different computers could create the same
lsid. if we use another authority, a centralized ID store would need to be
implemented to garauntee uniqueness. Another idea that's been thrown around is
using some sort of encryption key as the object identifier. Currently, kepler
uses localhost as the authority. There needs to be more discussion on exactly
how this should be changed.
The cache manager is now fully lsid compliant. There are no longer any
localhost lsids, instead they are kepler-project.org lsids. This works fine as
long as you don't try to lookup the lsid from the network, since there is
currently no lsid authority.
Original Bugzilla ID was 1883
Also available in: Atom
PDF