abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject FeedServer Review
Date Tue, 15 Jan 2008 21:09:03 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<body bgcolor="#ffffff" text="#000000">
Here are my thoughts:<br>
  <li>When creating an entry, it is not sufficient to have just an
Entry object. You need the whole RequestContext. This way you can
access things like headers, an HTTP session, etc. For instance, in my
application, the user has to supply an HTTP header when creating a
media entry which provides some extra metadata. [1]<br>
  <li>This is why the CollectionProvider works at the RequestContext
  <li>It doesn't handle media entries. Media entries are tricky. <br>
  <li>There is a lot of class.getName() and classloading going on which
seems to build on Abdera's usage of this in the ServiceContext. I'm not
a fan of this in general. IoC type frameworks should handle this for us
and if you're using the API its much easier to just do
setFoo(Foo.class) or even better setFoo(new Foo()); This is on my list
to look at refactoring.</li>
  <li>There is no workspace level abstraction. See WorkspaceInfo inside
the server module which can dynamically create workspaces in
conjunction with ServiceProvider. For instance, I could have
BlogWorkspaceInfo which was backed by a database of blogs. It would
then return a series of CollectionProviders for each blog. (We could
possibly return a less "heavy" object here, but creating a
CollectionProvider should not be resource intensive).<br>
  <li>FeedServerProvider doesn't seem very fleshed out at all.</li>
  <li>There is no error handling framework. <br>
  <li>I don't like the term "Adapter" on its own as its pretty
meaningless. I think there is something to be said for sticking with
*Provider all around as its consistent. I would be consdier
CollectionAdapter though.<br>
Keep in mind that AbstractCollectionProvider is *not* the only
CollectionProvider there can be. Take a look at the raw CP interface
and you'll see its a more powerful version of the Adapter interface.
You can easily write your sample JdbcAdapter and SampleAdapter by using
this interface.<br>
For instance, one could write a CollectionProvider like this:<br>
public class HowGoogleWantsToAccessFeeds implements CollectionProvider {<br>
&nbsp; public ResponseContext createEntry(RequestContext request) {<br>
&nbsp; &nbsp; &nbsp;&nbsp; Entry entry = createEntry(getEntryFromRequest(request));<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; entry = createEntry(entry);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ... do other stuff necessary
with entry;<br>
&nbsp; }<br>
&nbsp; public Entry createEntry(Entry entry) {<br>
&nbsp;&nbsp; ..... Use an entry how your adapter works now<br>
&nbsp; }<br>
Maybe AbstractCollectionProvider would be better renamed as
Abstract(Simple/Object/Entity)CollectionProvider. Then we could
abstract out some of the more common functionality for *all* CPs into
AbstractCollectionProvider. For example this bit of code would be work
for CollectionProviders:<br>
&nbsp;public ResponseContext createEntry(RequestContext request) {<br>
&nbsp;&nbsp;&nbsp; try {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MimeType contentType = request.getContentType();<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (isMediaType(contentType))<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return createMediaEntry(request);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return createNonMediaEntry(request);<br>
&nbsp;&nbsp;&nbsp; } catch (ParseException pe) {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .....<br>
&nbsp;&nbsp;&nbsp; }<br>
&nbsp; }<br>
The key here though is that this code *has* to be inside the CP. It
cannot work at the feed level as you may want to override this logic
for individual collections in a workspace/service. And you need the
RequestContext to do this. This is why we need an interface like
CollectionProviders and I think its much better to build adapters from
CPs to whatever else you want like I showed above or how I did with
Its looking to me like there are maybe some misunderstandings of the
ServiceProvider/CP code. This idea that CPs cannot work at the "data"
level is not correct. Hopefully that is clear from the above. Or maybe
I am just not understanding what you mean. Can you clarify what exactly
is missing? Or concrete improvements that you'd like to see? Or
possibly patches? I know there are things in the API that definitely
can be tweaked/improved. Maybe its not even the right paradigm, but the
Adapter classes seem to be a weaker version of this paradigm.<br>
If anything I think we need to start focusing on other things:<br>
- How do we enable opensearch &amp; paging on CPs<br>
- Can we build in better support for categories and comments threads?<br>
- Do we need to worry about concurrency issues in the model?<br>
- Dan<br>
<a class="moz-txt-link-freetext" href="http://svn.galaxy.muleforge.org/browse/galaxy/trunk/web/src/main/java/org/mule/galaxy/atom/ArtifactCollectionProvider.java?r=210#l144">http://svn.galaxy.muleforge.org/browse/galaxy/trunk/web/src/main/java/org/mule/galaxy/atom/ArtifactCollectionProvider.java?r=210#l144</a><br>
<pre class="moz-signature" cols="72">-- 
Dan Diephouse
<a class="moz-txt-link-freetext" href="http://mulesource.com">http://mulesource.com</a>
| <a class="moz-txt-link-freetext" href="http://netzooid.com/blog">http://netzooid.com/blog</a></pre>

View raw message