[Xen-API] Object refs vs uuids

["Alan Greenspan" <agreenspan@xxxxxxxxxxxxxxxxxxxxxxxx>]

Since all Xen Objects have UUIDs, what is the rationale behind opaque
temporary references?

As described below in the API spec, references are not valid across
sessions.  A Client that loses a connection to a XenServer is forced to
reacquire all of its references in order to contact Objects after
reestablishing a new session.   If the API was based on UUIDs, this
would not be necessary.   Also, as specified, multiple references to the
same Object are not guaranteed to be the same.  Therefore, clients
cannot test for equality based on reference.  So for example, a VIF
reference retrieved from a VM Object and a VIF reference retrieved from
a Network Object, though possibly different may in fact represent the
same VIF.  To make sense out of this, the client is forced in most cases
to obtain the UUID (in a separate call) after receiving a reference and
manage its model of the Xen world based on UUIDs.   Since there are no
API calls to get sets of UUIDs, after using a get_all API to retrieve a
set of references, the client must iterate over the set and translate to
UUIDs with individual API calls - fairly inefficient.

In addition to client complexity, XenServer implementations are burdened
by the need to generate references and manage the mapping of references
to UUIDs.  Lots of problems would seem to go away if the API was based
on UUIDs.



1.3.1 Note on References vs UUIDs
References are opaque types - encoded as XML-RPC strings on the wire -
understood only by the particular server which generated them. Servers
are free to choose any concrete representation they find convenient;
clients should not make any assumptions or attempt to parse the string
contents. References are not guaranteed to be permanent identifiers for
objects; clients should not assume that references generated during one
session are valid for any future session. References do not allow
objects to be compared for equality. Two references to the same object
are not guaranteed to be textually identical.
UUIDs are intended to be permanent names for objects. They are
guaranteed to be in the OSF DCE UUID presentation format (as output by
uuidgen. Clients may store UUIDs on disk and use them to lookup objects
in subsequent sessions with the server. Clients may also test equality
on objects by comparing UUID strings. The API provides mechanisms for
translating between UUIDs and opaque references. Each class that
contains a UUID field provides:
* A "get by uuid" method that takes a UUID, u, and returns an opaque
reference to the server-side object that has UUID=u;
* A get uuid function (a regular "field getter" RPC) that takes an
opaque reference, r, and returns the UUID of the server-side object that
is referenced by r.


_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api