abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jun Yang" <jyang...@gmail.com>
Subject Re: FeedServer Review
Date Thu, 17 Jan 2008 20:56:09 GMT
Hi Dan,

We were very happy when we first saw your stuff.  We even tried to see if we
should just subclass your provider.  But in the end we didn't because we
thought it would take too much time to first influence the code to support
dynamic adapter and then move to it.  We decided to release ours first,
receive some feedback and then merge.

We have always planned to copy your support for Workspace and all into our
provider.  So I think going forward, we can:

   1. Enhance AbstractProvider to support workspaces, etc. and pick other
   features to merge
   2. Add a StreamableAdapter to wrap Adapter and do streaming
   3. Keep Adapter as is

Thoughts?

Thanks!

Jun

On Jan 17, 2008 11:11 AM, Dan Diephouse <dan.diephouse@mulesource.com>
wrote:

>  Vasu Nori wrote:
>
> On Jan 16, 2008 11:39 AM, Dan Diephouse <dan.diephouse@mulesource.com> <dan.diephouse@mulesource.com>
> wrote:
>
>
>
>  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().
>
>
>
>  Dan
> sounds great.. I tried to do this but couldn't really figure out how to do
> this.
> could you please post an example to do this?
>
> thanks
>
>
>
>  Try looking at this:
>
>
> http://svn.galaxy.muleforge.org/browse/galaxy/trunk/web/src/main/java/org/mule/galaxy/atom/ArtifactVersionWorkspaceInfo.java?r=60
>
> In my application I have a collection of Artifacts. Each artifact has a
> collection of artifact versions. So I created a workspace for the artifact
> versions, but I didn't want to actually list out all the artifacts - that
> would be wayyyy too much time and too big of a services document. I created
> an ArtifactVersionWorkspaceInfo instead
>
> This is a slightly old example, so there would be 2 small differences now:
> 1. "id" would now be a URI fragment which you would have to parse. I.e.
> "artifactVersions/123"
> 2. I think you would have to return null if it wasn't found.
>
> Does that help?
>
> Also, I just want to clarify some things:
>
> 1. The reason I'm being a stickler about this stuff is that fundamentally
> I think we're trying to do the same thing API wise. Adapter/CP approaches
> are rather similar I think.
> 2. I'm also not saying the CP stuff is perfect. The API/ServiceProvider
> code could surely be cleaned up.
> 3. I strongly support the idea that we need an array of CPs/Adapters which
> don't necessarily require the developer. Like your JdbcAdapter. Or the
> JcrCollectionProvider. It'd be awesome if we just had a component which
> people could deploy which would do this. (Which seems to be what you're
> working on IIUC).
> 4. I don't really care too much if we go with Provider or Adapter as the
> name. I just think we should be consistent. It should either be
> (Service/Workspace/Collection)Provider or
> (Service/Workspace/Collection)Adapter.
>
> - Dan
>
> --
> Dan Diephouse
> MuleSourcehttp://mulesource.com | http://netzooid.com/blog
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message