abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject Re: FeedServer Review
Date Wed, 16 Jan 2008 19:39:05 GMT
Thanks for the thoughts which help clarify your thinking tremendously!

Vasu Nori wrote:
> 1. In the Adapter code, AdapterManager looks at the <feed>.properties file
> to figure  out which adapter class to load to serve the given feed.  In the
> usecases that we have encountered, we cannot assume that the server always
> knows about ALL the feeds it needs to serve. Datasources can be dynamically
> added which provide new feeds - and when the server receives a request with
> a new feedname in it, it needs to load the corresponding datasource adapter
> (connector or collectionprovider - whatever you want to call it).
>   
If you want to do this at the workspace level, this can all be done 
dynamically right now by implementing WorkspaceInfo. If you want to 
dynamically list out workspaces you extend AbstractServiceProvider and 
implement getWorkspaces().

You are right - there is a current limitation in the 
AbstractServiceProvider in that it needs to know up front about the 
workspaces. However, it does *not* need to know about the feeds. You 
would simply return an empty collection inside 
WorkspaceInfo.getCollectionProviders() when it was called. When you do 
access the feed that you don't know about before, 
AbstractServiceProvider calls getCollectionProvider(String href) and 
that will allow you to look it up dynamically.

> 2. properties file also includes certain other properties for feeds such as
> title, author, database sqlmap file name(if required) etc. I don't like
> hardcoding of any configurable attributes in java files.
>   
Thats fine. Lets create a flexible CollectionProvider that can use a 
properties file to load this info in and do the appropriate thing.
> 3. CollectionProvider(or, whatever we want to call it) only needs to have
> code that deals with accessing data from datasource. Any other code that
> DOES NOT deal with data from/to datassource - I would rather put it in a
> different class. Thats what we did by separating code into
> FeedServerProvider.java and Adapter(s).java.
>   
Are you referring to your issues with begin/end? We could put this 
inside of AbstractCollectionProvider. So we could do something like:

public class AbstractCollectionProvider {
public ResponseContext createEntry(RequestContext ctx) {
  ResponseContext response = null;
  try {
    begin(ctx);
    response = doCreateEntry(ctx);
  } finally {
    end(ctx, response);
  }
}

protected ResponseContext doCreateEntry(RequestContext ctx) {
}
}

Would that alleviate your concerns?
> 4. Can people write their own "collectionProviders"? sure. but why do that
> when we can make it easier by shipping a whole bunch of "adapters" (or
> collectionprovders) for most common datasources - all types of databases,
> filesystem etc. It was one of your stated goals that we should make writing
> a server easier.
>   
I agree that we should an array of CPs/Adapters/Whatever you want to 
call them. This is why I started the JCR adapter.
> 5. CollectionProvider can't be the one serving "service document".
> especially, since the server dynamically can expand the set of feeds it is
> serving (see point#1 above). we thought FeedserverProvider.java could be the
> place to have that code.
>   
See my explanation to #1, but this isn't the case. 
AbstractServiceProvider does this and can look them up dynamically. W
> The more I think about it, the more convinced I am that Dan's code is not
> that far away from our code. things can tweaked a little here or little
> there - but I would have happier if we agree on the concepts first..hope
> that makes sense.
I think we're making progress!

- Dan

-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog


Mime
View raw message