[Cosmo-dev] Cosmo WebUI Service Layer

[Travis Vachon]

>>>
>>> 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:
>
> <pastedGraphic.pdf>
>
>
> 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.
>

First, I understand the "organizational argument" here, this might be  
a nicer way to organize the problem. So you've got me partially  
convinced there..

Let's think quickly about what the Transport/Format Abstraction Layer  
(TAL) will need to look like:

1) We need it to support asynchronous or synchronous calls
2) We need to support multiple authentication methods (ticketed vs.  
owned by current user)

 From some offline chatter, I think you're thinking the TAL will look  
like:

cosmo.tal.json = {
saveItem(arg1, arg2, ..., transportInfo){},
...
other Item CRUD methods
...,
getCollections(arg1, arg2, ..., transportInfo){}
...
}

one way to implement saveItem would look like (apologies for the  
handwaving, and leaving out details about how the "synchronicity" of  
a call is passed):

saveItem(item, transportInfo){
	convert Item to JSON representation;
	if (call is synchronous) {
		if (transportInfo.ticketKey){
			jsonrpc-service.saveItem(item, ticketKey)
                 else (){
                         jsonrpc-service.saveItem(item)
		}
         }
	else{
		if (transportInfo.ticketKey){
			jsonrpc-service.saveItem(asyncHandlerMethod, item, ticketKey)
                 else (){
                         jsonrpc-service.saveItem(asyncHandlerMethod,  
item)
		}
	}
}


another possible implementation would be:

ticketedSaveItem(item, transportInfo){
	convert Item to JSON representation;
	if (call is synchronous){
		jsonrpc-service.saveItem(item, ticketKey)
	} else (){
		jsonrpc-service.saveItem(ayncHandlerMethod, item, ticketKey)
	}
}
ownedSaveItem(item, transportInfo){
	convert Item to JSON representation;
		if (call is synchronous){
		jsonrpc-service.saveItem(item, ticketKey)
	} else (){
		jsonrpc-service.saveItem(ayncHandlerMethod, item, ticketKey)
	}
}

This looks a lot like what we have in 0.6, except we have  
TicketedConduit.saveItem and OwnerConduit.saveItem.

A third option is to implement synchronousSaveItem and  
asynchronousSaveItem along these lines.

Whichever way you cut it, when you change transport layers you'll  
need to reimplement all of this, which I think would be pretty close  
to reimplementing "all four conduits."

To look at this another way:

In my proposal as posted, Conduits are responsible for several things:
1) Talking to the transport layer
2) Marshalling raw data into useful JS Objects that look like we want  
them to
3) Providing a useful API to client code (the UI)
4) Publishing to appropriate Topic channels on after (and before?) calls
5) (?) Providing some minimal error handling (perhaps mapping some  
server side exceptions to more useful client side exceptions)

Which of these things to you think should go into the Transport  
Abstraction Layer?



I think you might be right on this one, but I do want to think  
through things carefully before we add yet another layer.

-Travis