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
