[Dev] Uses of <cloudAlias>?

[Phillip J. Eby]

At 02:01 PM 6/1/2005 -0700, Morgen Sagen wrote:

>On May 31, 2005, at 8:27 PM, Phillip J. Eby wrote:
>>First, I noticed that in all cases where cloudAlias is used, it is
>>used on *all* of the "byCloud" endpoints in that cloud, and it
>>invariably matches the alias of that cloud.  In other words, clouds
>>aliased as the "default" cloud always use a cloudAlias
>>value="default", if they hav any cloudAlias elements.  My question:
>>is there ever a time that you would need to specify a *different*
>>cloud name?
>
>I can't think of a situation when traversing and endpoint by cloud
>should switch to a different cloud.  So not being able to specify a
>cloudAlias for an endpoint seems reasonable.
>>
>>Second, I found that of a total of 32 endpoints defined as
>>"byCloud", 9 of these did not have a cloudAlias element specified.
>>Are these defaulting to the same meaning as an explicit cloudAlias
>>with the same name as the alias of the defining cloud, or does it
>>mean something else altogether?
>
>I believe leaving the cloudAliases out of the endpoint definitions
>means the various methods such as Cloud.getItems( ) will use the
>cloudAlias that is passed to the method:
>
>    http://o11n.org/docs/current/api/repository.schema.Cloud.Cloud- 
> class.html#getItems
>
>...which I think we always pass.  As a test I removed all the
>cloudAlias values on every byCloud endpoint and things still worked.
>Unless I am missing something, I think we can get by without having
>cloudAliases defined on byCloud endpoints, since when it comes time
>to actually use them, we pass in a cloudAlias (such as "default", or
>"sharing") anyway.

Thanks Morgen.  Here's my proposed schema API for this, then:

      class Contact(ContentItem):

         contactName = schema.One(ContactName,
             inverse = ContactName.contact,
             initialValue=None
         )

         emailAddress = schema.One(schema.String,
             displayName="Email Address",
             initialValue=""
         )

         # ... more attributes here

         schema.addClouds(
             sharing = schema.Cloud(
                 byRef = [emailAddress], byCloud = [contactName]
             )
         )

In other words, you include a 'schema.addClouds()' call in the body of the 
class for a kind, and use keyword arguments to define individual clouds 
under their respective aliases.  The keyword arguments to the Cloud 
constructor define the inclusion policies, and each keyword takes a list of 
endpoint objects that follow that policy.  As a convenient shorthand, using 
an attribute object in place of an endpoint creates an endpoint with that 
name, for that attribute, since this is the most common kind of endpoint 
definition.

I'm thinking that the 'byCloud' keyword should set the cloudAlias to None, 
but if we need to be explicit about that later, we could add the cloud 
alias to the keyword.  For example:

         schema.addClouds(
             sharing = schema.Cloud(
                 byRef = [emailAddress], byCloud_sharing = [contactName]
             )
         )

This would set the cloudAlias for the contactName endpoint to "sharing".  A 
similar technique could also be used for byMethod, e.g. 
"byMethod_someMethod=[someAttr]", if it turns out we need that.

Initially, however, I would just do the basic keywords with no dynamic 
cloudAlias or method names.

Anybody have any comments?