You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by David Primmer <da...@gmail.com> on 2008/01/15 23:54:50 UTC
Re: FeedServer Review
I'll let Jun and Vasu respond in more detail later, but my general
impression of your comments is that they are not valuing the use case
that we were considering; namely that we wanted to make it easier to
produce an Atom interface to existing data sources that probably have
their own interface and accompanying local human administrative
expertise. We wanted to take the specifics of the Atom protocol out of
way of the dev in the same way that a high-level ORM can hide the
implementer from having to do SQL. That way, the user of the library
can focus on adapting the data sources and providing a read-write rest
web service.
The use case you seem to be focused on is targeting a developer of a
custom application that has an Atom interface which is more tightly
coupled to the data it is publishing. There's nothing wrong with a
more monolithic approach where the programmer controls all aspects of
the application, including storage and api and it may even allow a
cleaner or simpler design. This has probably been the primary use case
of Abdera at this point and it may be in the future. This allows much
more flexibility and optimization and should be available to those who
want to use it.
Tell me if this seems accurate: I see all these arguments as simply
presenting the case for different uses of Abdera. These server
implementations all pick an arbitrary points to stop putting
constraints on the user. Our approach is more product-oriented,
favoring 'convention over configuration' and you are sticking closer
to the open framework roots of Abdera. Isn't there a way that both can
exist in the codebase without confusing the developer?
On Jan 15, 2008 1:09 PM, Dan Diephouse <da...@mulesource.com> wrote:
>
> Here are my thoughts:
>
> 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).
We made efforts to not duplicate your workspace design and were aware
that our server implementation did not have this level of abstraction.
This was in anticipating of merging with your code.
> 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.
The term Provider acts like a gaussian blur to my eyes. And generally
adds nothing to whatever it is attached to. What is a Provider?
Adapter at least hints at the fact that it changes something from one
format to another while allowing the endpoints to connect easily.
Again, this is a matter of the product design perspective you come
from. Were looking at using this with legacy data. If you're coding
the whole thing from scratch and agnostic to back-end storage format,
Adapter seems like a dumb name.
hope this helps.
davep
Re: FeedServer Review
Posted by Dan Diephouse <da...@mulesource.com>.
Jun Yang wrote:
> 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.
>
I don't have any problem with that. What I do have issues with is
throwing two mechanisms into the codebase when we could just address
your use cases and try to fill the gaps. We just need to understand what
those issues are.
> We have always planned to copy your support for Workspace and all into our
> provider.
Are we talking about the feedserver codebase here or Abdera?
> So I think going forward, we can:
>
> 1. Enhance AbstractProvider to support workspaces, etc. and pick other
> features to merge
>
We've already got AbstractServiceProvider which handles workspaces. Can
you please explain why we need another mechanism?
> 3. Keep Adapter as is
>
I've already highlighted the limitations of the Adapter interface.
Specifically it can't handle things like headers & media entries. Which
if we're going to make any type of prebundled atom stores (i.e. JDBC or
JCR), then this will need to be addressed. In essence the Adapter needs
to take RequestContext as a parameter and return a ResponseContext. As
soon as you do this to the Adapter interface you'll realize that is
pretty much the exact same thing as the CollectionProvider. So I stand
by my assertion that the Adapter interface itself is pretty redundant
and I think we should stick with/enhance whats in there.
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: FeedServer Review
Posted by Jun Yang <jy...@gmail.com>.
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 <da...@mulesource.com>
wrote:
> Vasu Nori wrote:
>
> On Jan 16, 2008 11:39 AM, Dan Diephouse <da...@mulesource.com> <da...@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
>
>
Re: FeedServer Review
Posted by Vasu Nori <va...@gmail.com>.
On Jan 16, 2008 11:39 AM, Dan Diephouse <da...@mulesource.com>
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().
>
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
Re: FeedServer Review
Posted by Dan Diephouse <da...@mulesource.com>.
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
Re: FeedServer Review
Posted by Vasu Nori <va...@gmail.com>.
I looked at JcrCollectionProvider.java.
Dan is right - CollectionProvider is **like** Adapter - with a few
differences.
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).
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.
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.
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.
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.
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.
thanks
On Jan 16, 2008 6:51 AM, Dan Diephouse <da...@mulesource.com> wrote:
>
> David Primmer wrote:
> > I'll let Jun and Vasu respond in more detail later, but my general
> > impression of your comments is that they are not valuing the use case
> > that we were considering; namely that we wanted to make it easier to
> > produce an Atom interface to existing data sources that probably have
> > their own interface and accompanying local human administrative
> > expertise. We wanted to take the specifics of the Atom protocol out of
> > way of the dev in the same way that a high-level ORM can hide the
> > implementer from having to do SQL. That way, the user of the library
> > can focus on adapting the data sources and providing a read-write rest
> > web service.
> >
> >
> Great, I think this is a very valuable use case.
>
> What I'm confused about is why we need a new mechanism to do this. I
> already went through and provided an example of how the
> CollectionProvider can support both your needs and general developer
> requirements.
>
> Can you please provide some concrete examples of why the CP code cannot
> be used or why the Adapter approach is easier to use? I roughly
> understand what you're saying about how you're trying to focus on
> adapting data sources, but I still don't see why this can't be done with
> the CP code and why we need a completely new implementation/paradigm to
> do it.
>
> Would you be opposed to writing a AbstractDataSourceCollectionProvider?
> (I don't really care that much about naming, but hopefully its clear
> what I mean from the context). This would work with the existing
> ServiceProvider, reuse the existing approach and provide you with the
> interface you want.
> > If you're coding
> > the whole thing from scratch and agnostic to back-end storage format,
> > Adapter seems like a dumb name.
> >
> I never said it sounded dumb. I said it just wasn't consistent. I too am
> not a huge fan of the *Provider naming, but thats a rabbit hole that we
> can revisit later as its really not as important as the interfaces for
> interacting with the system.
>
> - Dan
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
>
>
Re: FeedServer Review
Posted by Dan Diephouse <da...@mulesource.com>.
David Primmer wrote:
> I'll let Jun and Vasu respond in more detail later, but my general
> impression of your comments is that they are not valuing the use case
> that we were considering; namely that we wanted to make it easier to
> produce an Atom interface to existing data sources that probably have
> their own interface and accompanying local human administrative
> expertise. We wanted to take the specifics of the Atom protocol out of
> way of the dev in the same way that a high-level ORM can hide the
> implementer from having to do SQL. That way, the user of the library
> can focus on adapting the data sources and providing a read-write rest
> web service.
>
>
Great, I think this is a very valuable use case.
What I'm confused about is why we need a new mechanism to do this. I
already went through and provided an example of how the
CollectionProvider can support both your needs and general developer
requirements.
Can you please provide some concrete examples of why the CP code cannot
be used or why the Adapter approach is easier to use? I roughly
understand what you're saying about how you're trying to focus on
adapting data sources, but I still don't see why this can't be done with
the CP code and why we need a completely new implementation/paradigm to
do it.
Would you be opposed to writing a AbstractDataSourceCollectionProvider?
(I don't really care that much about naming, but hopefully its clear
what I mean from the context). This would work with the existing
ServiceProvider, reuse the existing approach and provide you with the
interface you want.
> If you're coding
> the whole thing from scratch and agnostic to back-end storage format,
> Adapter seems like a dumb name.
>
I never said it sounded dumb. I said it just wasn't consistent. I too am
not a huge fan of the *Provider naming, but thats a rabbit hole that we
can revisit later as its really not as important as the interfaces for
interacting with the system.
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: FeedServer Review
Posted by James M Snell <ja...@gmail.com>.
No particular rush, I just think better when there's code available ;-).
FWIW, I had been planning on putting the code into the contrib module
for now, which, along with the fact that it doesn't change any existing
classes, would make it a pretty zero impact check-in.
- James
Dan Diephouse wrote:
> I think its pretty typical at Apache that you try to gain consensus
> about controversial patches first.
>
> Why the rush to stick it in SVN anyway? I'm sure we'll figure out what
> to do soon. We're having good healthy discussion :-)
>
> - Dan
>
> James M Snell wrote:
>> I disagree. Putting the code into the repository does not commit us to
>> anything and gives us all a base from which to iterate. Discussion
>> can and will still happen.
>>
>> - James
>>
>> Dan Diephouse wrote:
>>> I think its a little early to check code in as we're in the midst of
>>> a discussion about this still. Once the discussion wraps up I'm sure
>>> we'll have a clearer idea of what to do.
>>>
>>> James M Snell wrote:
>>>> Yep, the two approaches can certainly coexist, we just need to work
>>>> out the details. The first step needs to be getting the Adapter
>>>> stuff checked in (or, at the very least, get a jira issue opened)
>>>> and then start iterating from there.
>>>>
>>>> - James
>>>>
>>>> David Primmer wrote:
>>>>> [snip]
>>>>> Tell me if this seems accurate: I see all these arguments as simply
>>>>> presenting the case for different uses of Abdera. These server
>>>>> implementations all pick an arbitrary points to stop putting
>>>>> constraints on the user. Our approach is more product-oriented,
>>>>> favoring 'convention over configuration' and you are sticking closer
>>>>> to the open framework roots of Abdera. Isn't there a way that both can
>>>>> exist in the codebase without confusing the developer?
>>>>>
>>>>>
>>>>> On Jan 15, 2008 1:09 PM, Dan Diephouse
>>>>> <da...@mulesource.com> wrote:
>>>>>> Here are my thoughts:
>>>>>>
>>>>>> 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).
>>>>>
>>>>>
>>>>> We made efforts to not duplicate your workspace design and were aware
>>>>> that our server implementation did not have this level of abstraction.
>>>>> This was in anticipating of merging with your code.
>>>>>
>>>>>
>>>>>> 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.
>>>>>
>>>>> The term Provider acts like a gaussian blur to my eyes. And generally
>>>>> adds nothing to whatever it is attached to. What is a Provider?
>>>>> Adapter at least hints at the fact that it changes something from one
>>>>> format to another while allowing the endpoints to connect easily.
>>>>> Again, this is a matter of the product design perspective you come
>>>>> from. Were looking at using this with legacy data. If you're coding
>>>>> the whole thing from scratch and agnostic to back-end storage format,
>>>>> Adapter seems like a dumb name.
>>>>>
>>>>> hope this helps.
>>>>>
>>>>> davep
>>>>>
>>>
>>>
>
>
Re: FeedServer Review
Posted by Dan Diephouse <da...@mulesource.com>.
I think its pretty typical at Apache that you try to gain consensus
about controversial patches first.
Why the rush to stick it in SVN anyway? I'm sure we'll figure out what
to do soon. We're having good healthy discussion :-)
- Dan
James M Snell wrote:
> I disagree. Putting the code into the repository does not commit us to
> anything and gives us all a base from which to iterate. Discussion
> can and will still happen.
>
> - James
>
> Dan Diephouse wrote:
>> I think its a little early to check code in as we're in the midst of
>> a discussion about this still. Once the discussion wraps up I'm sure
>> we'll have a clearer idea of what to do.
>>
>> James M Snell wrote:
>>> Yep, the two approaches can certainly coexist, we just need to work
>>> out the details. The first step needs to be getting the Adapter
>>> stuff checked in (or, at the very least, get a jira issue opened)
>>> and then start iterating from there.
>>>
>>> - James
>>>
>>> David Primmer wrote:
>>>> [snip]
>>>> Tell me if this seems accurate: I see all these arguments as simply
>>>> presenting the case for different uses of Abdera. These server
>>>> implementations all pick an arbitrary points to stop putting
>>>> constraints on the user. Our approach is more product-oriented,
>>>> favoring 'convention over configuration' and you are sticking closer
>>>> to the open framework roots of Abdera. Isn't there a way that both can
>>>> exist in the codebase without confusing the developer?
>>>>
>>>>
>>>> On Jan 15, 2008 1:09 PM, Dan Diephouse
>>>> <da...@mulesource.com> wrote:
>>>>> Here are my thoughts:
>>>>>
>>>>> 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).
>>>>
>>>>
>>>> We made efforts to not duplicate your workspace design and were aware
>>>> that our server implementation did not have this level of abstraction.
>>>> This was in anticipating of merging with your code.
>>>>
>>>>
>>>>> 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.
>>>>
>>>> The term Provider acts like a gaussian blur to my eyes. And generally
>>>> adds nothing to whatever it is attached to. What is a Provider?
>>>> Adapter at least hints at the fact that it changes something from one
>>>> format to another while allowing the endpoints to connect easily.
>>>> Again, this is a matter of the product design perspective you come
>>>> from. Were looking at using this with legacy data. If you're coding
>>>> the whole thing from scratch and agnostic to back-end storage format,
>>>> Adapter seems like a dumb name.
>>>>
>>>> hope this helps.
>>>>
>>>> davep
>>>>
>>
>>
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: FeedServer Review
Posted by James M Snell <ja...@gmail.com>.
I disagree. Putting the code into the repository does not commit us to
anything and gives us all a base from which to iterate. Discussion can
and will still happen.
- James
Dan Diephouse wrote:
> I think its a little early to check code in as we're in the midst of a
> discussion about this still. Once the discussion wraps up I'm sure we'll
> have a clearer idea of what to do.
>
> James M Snell wrote:
>> Yep, the two approaches can certainly coexist, we just need to work
>> out the details. The first step needs to be getting the Adapter stuff
>> checked in (or, at the very least, get a jira issue opened) and then
>> start iterating from there.
>>
>> - James
>>
>> David Primmer wrote:
>>> [snip]
>>> Tell me if this seems accurate: I see all these arguments as simply
>>> presenting the case for different uses of Abdera. These server
>>> implementations all pick an arbitrary points to stop putting
>>> constraints on the user. Our approach is more product-oriented,
>>> favoring 'convention over configuration' and you are sticking closer
>>> to the open framework roots of Abdera. Isn't there a way that both can
>>> exist in the codebase without confusing the developer?
>>>
>>>
>>> On Jan 15, 2008 1:09 PM, Dan Diephouse <da...@mulesource.com>
>>> wrote:
>>>> Here are my thoughts:
>>>>
>>>> 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).
>>>
>>>
>>> We made efforts to not duplicate your workspace design and were aware
>>> that our server implementation did not have this level of abstraction.
>>> This was in anticipating of merging with your code.
>>>
>>>
>>>> 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.
>>>
>>> The term Provider acts like a gaussian blur to my eyes. And generally
>>> adds nothing to whatever it is attached to. What is a Provider?
>>> Adapter at least hints at the fact that it changes something from one
>>> format to another while allowing the endpoints to connect easily.
>>> Again, this is a matter of the product design perspective you come
>>> from. Were looking at using this with legacy data. If you're coding
>>> the whole thing from scratch and agnostic to back-end storage format,
>>> Adapter seems like a dumb name.
>>>
>>> hope this helps.
>>>
>>> davep
>>>
>
>
Re: FeedServer Review
Posted by Dan Diephouse <da...@mulesource.com>.
I think its a little early to check code in as we're in the midst of a
discussion about this still. Once the discussion wraps up I'm sure we'll
have a clearer idea of what to do.
James M Snell wrote:
> Yep, the two approaches can certainly coexist, we just need to work
> out the details. The first step needs to be getting the Adapter stuff
> checked in (or, at the very least, get a jira issue opened) and then
> start iterating from there.
>
> - James
>
> David Primmer wrote:
>> [snip]
>> Tell me if this seems accurate: I see all these arguments as simply
>> presenting the case for different uses of Abdera. These server
>> implementations all pick an arbitrary points to stop putting
>> constraints on the user. Our approach is more product-oriented,
>> favoring 'convention over configuration' and you are sticking closer
>> to the open framework roots of Abdera. Isn't there a way that both can
>> exist in the codebase without confusing the developer?
>>
>>
>> On Jan 15, 2008 1:09 PM, Dan Diephouse <da...@mulesource.com>
>> wrote:
>>> Here are my thoughts:
>>>
>>> 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).
>>
>>
>> We made efforts to not duplicate your workspace design and were aware
>> that our server implementation did not have this level of abstraction.
>> This was in anticipating of merging with your code.
>>
>>
>>> 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.
>>
>> The term Provider acts like a gaussian blur to my eyes. And generally
>> adds nothing to whatever it is attached to. What is a Provider?
>> Adapter at least hints at the fact that it changes something from one
>> format to another while allowing the endpoints to connect easily.
>> Again, this is a matter of the product design perspective you come
>> from. Were looking at using this with legacy data. If you're coding
>> the whole thing from scratch and agnostic to back-end storage format,
>> Adapter seems like a dumb name.
>>
>> hope this helps.
>>
>> davep
>>
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: FeedServer Review
Posted by Vasu Nori <va...@gmail.com>.
I have created a new issue in Jira to address adapters issue (key =
ABDERA-88).
thanks
On Jan 15, 2008 3:12 PM, James M Snell <ja...@gmail.com> wrote:
> Yep, the two approaches can certainly coexist, we just need to work out
> the details. The first step needs to be getting the Adapter stuff
> checked in (or, at the very least, get a jira issue opened) and then
> start iterating from there.
>
> - James
>
> David Primmer wrote:
> > [snip]
> > Tell me if this seems accurate: I see all these arguments as simply
> > presenting the case for different uses of Abdera. These server
> > implementations all pick an arbitrary points to stop putting
> > constraints on the user. Our approach is more product-oriented,
> > favoring 'convention over configuration' and you are sticking closer
> > to the open framework roots of Abdera. Isn't there a way that both can
> > exist in the codebase without confusing the developer?
> >
> >
> > On Jan 15, 2008 1:09 PM, Dan Diephouse <da...@mulesource.com>
> wrote:
> >> Here are my thoughts:
> >>
> >> 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).
> >
> >
> > We made efforts to not duplicate your workspace design and were aware
> > that our server implementation did not have this level of abstraction.
> > This was in anticipating of merging with your code.
> >
> >
> >> 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.
> >
> > The term Provider acts like a gaussian blur to my eyes. And generally
> > adds nothing to whatever it is attached to. What is a Provider?
> > Adapter at least hints at the fact that it changes something from one
> > format to another while allowing the endpoints to connect easily.
> > Again, this is a matter of the product design perspective you come
> > from. Were looking at using this with legacy data. If you're coding
> > the whole thing from scratch and agnostic to back-end storage format,
> > Adapter seems like a dumb name.
> >
> > hope this helps.
> >
> > davep
> >
>
Re: FeedServer Review
Posted by James M Snell <ja...@gmail.com>.
Yep, the two approaches can certainly coexist, we just need to work out
the details. The first step needs to be getting the Adapter stuff
checked in (or, at the very least, get a jira issue opened) and then
start iterating from there.
- James
David Primmer wrote:
> [snip]
> Tell me if this seems accurate: I see all these arguments as simply
> presenting the case for different uses of Abdera. These server
> implementations all pick an arbitrary points to stop putting
> constraints on the user. Our approach is more product-oriented,
> favoring 'convention over configuration' and you are sticking closer
> to the open framework roots of Abdera. Isn't there a way that both can
> exist in the codebase without confusing the developer?
>
>
> On Jan 15, 2008 1:09 PM, Dan Diephouse <da...@mulesource.com> wrote:
>> Here are my thoughts:
>>
>> 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).
>
>
> We made efforts to not duplicate your workspace design and were aware
> that our server implementation did not have this level of abstraction.
> This was in anticipating of merging with your code.
>
>
>> 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.
>
> The term Provider acts like a gaussian blur to my eyes. And generally
> adds nothing to whatever it is attached to. What is a Provider?
> Adapter at least hints at the fact that it changes something from one
> format to another while allowing the endpoints to connect easily.
> Again, this is a matter of the product design perspective you come
> from. Were looking at using this with legacy data. If you're coding
> the whole thing from scratch and agnostic to back-end storage format,
> Adapter seems like a dumb name.
>
> hope this helps.
>
> davep
>