[Cosmo-dev] Cosmo WebUI Service Layer

Bobby Rullo br at osafoundation.org
Tue Mar 6 14:07:36 PST 2007


More comments inline:

On Mar 5, 2007, at 4:24 PM, Travis Vachon wrote:

>>>
>>
>> Don't know what you mean by this...Why wouldn't we need a place  
>> for them to live before? Or are you  responding to "where do you  
>> find the current conduits"?
> Sorry, this was poorly worded, what I really meant was "we'll need  
> to find somewhere for the API that _uses_ that Conduit API to live  
> (that is, the API that is used by the UI). In many cases, these  
> will simply be functions that call methods on the  
> DefaultCurrentUserConduit.
>>

I still don't understand....Could you splain as if I had no idea what  
you were talking about?

>>
>> I don't think stuff like getCollections, getSubscriptions etcetera  
>> need the conduit abstraction layer, since they can only be gotten  
>> through one way. That is, you would never use a ticketed  
>> collection conduit to get the user's preferences.
> Well, I feel _very_ strongly that these things need to be in the  
> Conduit layer somewhere. The Conduit layer is meant to be used for  
> _all_ client-server interaction. The case you give is the reason  
> that preference methods only appear in the CurrentUserConduit, and  
> not  the base level Conduit.
>>

I don't buy that. I don't think conduits make sense for this other  
stuff. Mutiple conduits are needed for the items, collections and all  
the stuff that's part of the Chandler Data model.

I see the layers as more like this:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.pdf
Type: application/pdf
Size: 33342 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/cosmo-dev/attachments/20070306/3c328c9d/pastedGraphic-0001.pdf
-------------- next part --------------


They way you propose things, every conduit has to have knowledge of  
JSON-RPC or whatever protocol/format we chose to use. That means when  
the time comes to switch to GDATA or GData++ or MorseCode Delux we  
have to write four new conduits. Whereas in the above model, you'd  
only rewrite the Transport Abstraction Layer. The conduits all  
implement the same methods, which are CRUD related methods for Item  
data. Since user preferences, system info cannot be obtained through  
multiple channels there is no need for it to exist in the conduit API  
where only one conduit will ever implement it.


>
> Perhaps cosmo.service.newCollection(), where the call knows to use  
> the DefaultCurrentUserCollection?

right, as well as cosmo.service.newSubscription() and others possibly.





More information about the cosmo-dev mailing list