abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Re: Server module refactoring
Date Sat, 19 Jan 2008 18:39:49 GMT


Dan Diephouse wrote:
> I've commented on a couple things which I have other thoughts on, but 
> overall it looks good.
> 
> James M Snell wrote:
>>
>> The default provider implementation will extend 
>> AbstractWorkspaceManagerProvider.java.  This class implements boththe 
>> Provider and WorkspaceManager interfaces.
> I would also like to float the idea that the Provider should take a 
> WorkspaceManager as a property/constructor. This way I as a user just 
> implement WorkspaceManager which can look up collections from my 
> database and pass it in as an argument to some stock Provider.
>>
>> The WorkspaceManager is equivalent to the current WorkspaceInfo 
>> interface.  It's primary function is to lookup the appropriate 
>> CollectionAdapter instance.
> We still need a way to describe the workspaces though. A la 
> WorkspaceInfo.getName/getCollectionProviders. Are you sure we don't need 
> WorkspaceInfo still?
> 

WorkspaceInfo is still going to be there, it will be used for 
Provider/Adapter implentations that derived from what is currently your 
CollectionProvider code, which I am currently in the process of 
porting/adapting over the revised model.  Once I finish porting and you 
get a chance to review, I think it will make sense.

>>
>> A CollectionAdapter instance can choose to implement the Provider 
>> interface in order to support extension methods.
> I'm not sure that provider is the right interface to do this as it mixes 
> semantics a little bit. My alternative proposals would be to either:
> 1. have a fallback method built into CA like doOther(RequestContext) or 
> something like that.
> 2. Make the Provider responsible for choosing a method via some sort of 
> extensible dispatching mechanism

Yes, I'm not convinced Provider is right either.  For now, it suited the 
immediate need but I was planning to revisit it.

>>
>> A CollectionAdapter instance can choose to implement the Transactional 
>> interface if it wishes to support begin/end/compensate semantics.
> I think this might be going a little bit overboard here in terms of 
> interfaces. I would rather lean toward building this into the 
> AbstractCollectionAdapter itself. A la the code snippet I published 
> earlier which called begin/end inside.
> 
> BTW, I also think we'll need to have begin/end points which we can 
> intercept in the actual Provider implementation itself.
> 

Noted. Once I finish the initial port, I'll check the code into a branch 
so we can collectively review it and make whatever additional tweaks we 
need.

> Overall, I like the simplified flow and increased coherency!
> 

Excellent.

- James

> - Dan
> 

Mime
View raw message