Summary

OSID Id Consumers

Strings Are Opaque

An OSID Id can be used as an argument to any OSID method parameter that specifies an Id. They are generally used for retrieving, updating or deleting OsidObjects.

OSID Consumers should treat the identification components as opaque. Upon examining the components of an OSID Id retrieved from an OSID Provider, there may be information inside that can be acted upon programmatically, such as a path name or a URL. Resist the temptation!

If you want your application to work across OSID Providers and be adaptable to a variety of circumstances, do not code anything that depends on the values inside an Id as the meaning and nature of the identifier is specific to each OSID Provider, even if you find clusters of OSID Providers doing similar things.

Persisting

The Id components can be persisted to save state. There is no specified limit on how large the identifier can be but various GUID schemes can produce identifiers in the hundreds of bytes. Some databases do not implement true variable-sized text, in which case be generous in column sizes. OSID Ids will grow in federations to incorporate routing information.

Because of the opaque and random nature of OSID Ids, they are not optimal for use as a database primary key. Where it is expected to construct relationships, use a more efficient integer-based identifier as a primary key, and store the OSID Id in a separate indexed column.

Preserving Compatibility

The Federating Problem

Where To Solve The Problem

While each OSID Provider is responsible for issuing unique Ids, there is no guarantee that any two OSID Providers issue unique Ids. Some implementors of OSID Providers try and predict this dilemma by using globally unique identification schemes, only to find that an OSID Adapter instantiated that implementation twice producing the Id collisions.

A rule of thumb if that an implementor of an OSID Provider should not be concerned with how it might be applied. Keep it simple. For example, a database -oriented OSID Provider might issue Ids based on:

identifier: primary key
namespace: table name
authority: localhost

Federation is the problem of the federators, not the underlying OSID Providers.

Dumb and Blind Federators

The simplest federating OSID Adapter has no knowledge of which Ids belong to what OSID Providers. It tries them all.

Routing Based On Authority

Dynamic Routing

Id Tagging

Id Masking

See Also

Browser not supported