[Cosmo-dev] Cosmo WebUI Service Layer

[Bobby Rullo]

Overall seems pretty good. Here are my comments:

> "Therefore, there should be a single Conduit instance for  
> interacting with a user's "Owned" collections, and a single Conduit  
> instance for each ticket in a user's subcriptions."


I think it's more accurate to say "...a single Conduit for each of a  
user's subscriptions" - which would probably be the same as one for  
each ticket.

> Example: retry
> There will, in the future...

I would also like to see a way for the owner conduit and subscription  
conduit (and all other conduits which require login) to prompt the  
user to re-login if they've timed out and then automatically retry  
the request.

> Please see the dojo.Deferred API reference for more information  
> about Deferreds.

Doesn't really tell you that much unfortunately...

>  Model Data Convenience Syntax

Looks ok, but still worried about this for some reason.

Why does the collection object have a getItem()? Items don't belong  
to a particular collection and you can identify them solely with the  
UID.

> The Conduit API will be stable enough for business object use.  
> However, it is recommended that developers use the Model Data  
> Convenience affordances whenever possible.:

I'm thinking we should insist that other code only use the MDC stuff.  
The MDC api is likely to be more stable, and I'd rather not have to  
make the UI dev manually inject conduits into newly created items/ 
collections.

> item.doDelete()

why not "delete()"?

Also, what do we do about "new" items? Does the conduit become like  
an item factory - "var item = conduit.newItem()" ?

For MDC we could do "var item = collection.newItem()"

But then how do you get a new collection?

Also, how does the one (if one can) get a handle on the list of  
conduits that are "loaded"?

Bobby