abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vasu Nori" <vasun...@gmail.com>
Subject Re: Feedback round 2 [was Re: Server Refactoring - Overview]
Date Tue, 22 Jan 2008 19:44:25 GMT
never mind my prev email. found the change branch with refactored code.



On Jan 22, 2008 11:17 AM, Vasu Nori <vasunori@gmail.com> wrote:

> James/Dan
>
> I have just had a chance to look at this email thread about server
> refactoring work.
> Sounds great. can't wait to see the new code and figure out how google
> feedserver code can fit in..
>
> Is this code in trunk or in some other change-branch?
> I got the latest from trunk - but can't find the changes you are talking
> about.
>
> any pointers?
>
> thanks
>
>
> On Jan 22, 2008 8:20 AM, James M Snell < jasnell@gmail.com> wrote:
>
> >
> > Dan Diephouse wrote:
> > > Looking good. But even more new comments! Hopefully you aren't sick of
> >
> > > me yet :-)
> > >
> >
> > Never!  Of course, large payments of small unmarked bills would help ;-)
> >
> > > Can we collapse ServiceContext and Provider? I would propose then that
> > > Provider gets getters/setters for Resolver<Subject>/<Target>. If
we
> > did
> > > this we could get rid of ServiceContext too I think -- which would
> > > remove one more step for the user. I did a similar thing with when I
> > > made it implement Resolver<Target>. While I think this should be
> > > pluggable, I really think users should not have to configure a
> > resolver
> > > by default.
> > >
> >
> > Quite possibly. Will take a look today.
> >
> > > Along these lines I think we should remove the instantiation code
> > which
> > > is in DefaultServiceContext. IMO this is the job of a container of
> > some
> > > sort. I mean container in the broadest sense here.  For instance, I
> > > think it could be wrapped up in something like a
> > > PropertiesProviderBuilder. It could then configure a whole provider
> > > instance - including resolvers, workspace manager, and
> > collectionadapters.
> > >
> >
> > Agreed.
> >
> > > Transactional.begin/end needs to take RequestContext so I can store a
> > > JCR session in it.
> > >
> >
> > Ok, will add that today.
> >
> > > The JCR tests provide a good means to test if the basic
> > ServiceProvider
> > > stuff I wrote still roughly works.
> > >
> >
> > Well, it would need to be ported to the new model as the interfaces have
> >
> >  changed.  Would you like to take a stab at that?  Doing so would help
> > you get a better feeling for the new design.
> >
> > > My feeling is that CollectionInfo should not extend CollectionAdapter.
> >
> > > While I agree that people will probably implement both CollectionInfo
> > > and CollectionAdapter by default, sometimes you want to just return
> > the
> > > metadata.
> > >
> >
> > Agreed.  CollectionInfo can have a getCollectionAdapter method to
> > connect the two.
> >
> > > Re: BasicAdapter - I'm still unconvinced about this API and its
> > ability
> > > to support the necessary semantics for generic APP stores.
> > >
> >
> > Ditto.
> >
> > > CollectionAdapterManager should be in the basic package if we keep the
> > > basic stuff around.
> > >
> >
> > Take another look at CAM; I modified it so that it works generically
> > with any CollectionAdapter, not just BasicAdapter.  This would allow any
> > Provider implementation to use the properties file deployment mechanism
> > independently of whether the BasicAdapter interface is used.
> >
> > > I get the feeling that
> > > WorkspaceManager.checkMethod/checkTarget/getMethods can all probably
> > go.
> > > Could we not work that logic into the
> > CollectionAdapter.extensionRequest?
> > >
> >
> > Not sure about this.
> >
> > > I still don't think its a good idea for a Provider to act as its own
> > > WorkspaceManager per my previous email.
> > >
> >
> > Noted, but it does make things easier in some cases (see the Simple
> > example).  However, the design assumes they are separate things.
> >
> > > Shouldn't the WorkspaceInfo logic in DefaultProvider be in
> > > WorkspaceManager?
> > >
> >
> > Possibly; will take another look.
> >
> > - James
> >
> > > - Dan
> > > James M Snell wrote:
> > >> Ok, the server refactoring is coming along very well I think.  Thus
> > >> far, I've been able to greatly simplify the overall design, as well
> > as
> > >> integrate the approaches implemented by Dan and the google
> > feed-server
> > >> team while still maintaining the flexibility of the original
> > framework.
> > >>
> > >> The main components of the refactored design are:
> > >>
> > >>  * AbderaServlet
> > >>  * ServiceContext
> > >>  * Provider
> > >>  * WorkspaceManager
> > >>  * CollectionAdapter
> > >>  * RequestContext
> > >>  * ResponseContext
> > >>  * Target
> > >>  * Resolver<Target>
> > >>  * Resolver<Subject>
> > >>
> > >> For the overwhelming majority of implementations, all an end
> > developer
> > >> will need to do is implement a CollectionAdapter, provide a
> > >> TargetResolver, and glue the two together using a ServiceContext.
> > >>
> > >> The examples in the server_refactor test cases illustrates the three
> > >> fundamental approaches.
> > >>
> > >> The application flow is simple:
> > >>
> > >>  * The AbderaServlet receives a request and creates a ServiceContext
> > >>  * The ServiceContext creates a Provider instance
> > >>  * The Provider instance uses it's associated WorkspaceManager to
> > >>    select a CollectionAdapter.
> > >>  * Once the CollectionAdapter is selected, the Provider forwards the
> > >>    request on to the appropriate method
> > >>
> > >> In some cases, the Provider and the WorkspaceManager will be the same
> >
> > >> object.  In other cases, the Provider and the WorkspaceManager will
> > be
> > >> separate.
> > >>
> > >> Simple
> > >> ------
> > >>
> > >> In the Simple example, the developer implements a CollectionAdapter,
> > a
> > >> Provider and a ServiceContext.
> > >>
> > >> The CollectionAdapter provides the guts of the implementation,
> > >> providing implementations for each of the main prototocol operations
> > >> such as getFeed, getEntry, etc.  These are the methods that used to
> > >> exist on the old style provider interface.
> > >>
> > >> The Provider extends AbstractWorkspaceProvider which means the
> > >> Provider is acting as it's own WorkspaceManager.
> > >>
> > >> The Provider/WorkspaceManager dispatches requests to the
> > SimpleAdapter
> > >> implementation.
> > >>
> > >> The SimpleServiceContext glues the Provider to the appropriate target
> > >> resolver.
> > >>
> > >> Default
> > >> -------
> > >>
> > >> In the Default example, the developer uses the same CollectionAdapter
> > >> implementation used in the simple example but uses the
> > DefaultProvider
> > >> class.
> > >>
> > >> The Default example is similar in nature to the CollectionProvider
> > >> stuff implemented by Dan in that it is the DefaultProvider's job to
> > >> handle things like the creation of the Service document based on
> > >> metadata provided by the developer.
> > >>
> > >> The simple and default examples are nearly identical with the
> > >> exception that the default example supports multiple workspaces and
> > >> collections.
> > >>
> > >> Basic
> > >> -----
> > >>
> > >> The basic example (which is poorly named, I know) is essentially the
> > >> google feed-server stuff, slightly modified so that it sits on top of
> >
> > >> the default provider implementation.
> > >>
> > >> The properties file based deployment is kept intact, but the Adapter
> > >> interface is replaced by the BasicAdapter abstract class, which is an
> >
> > >> abstract CollectionAdapter implementation that defines the same
> > >> abstract methods defined by the google feed-server Adapter interface.
> > >> Existing google feed-server Adapter implementations can be ported to
> > >> this design simply by replacing "implements Adapter" with "extends
> > >> BasicAdapter".
> > >>
> > >> The implementation has been further modified to support the creation
> > >> of a service document.  The code will read all of the *.properties
> > >> files for the adapters and will generate a service document with one
> > >> workspace and one collection per configured adapter.
> > >>
> > >> Service Documents
> > >> -----------------
> > >>
> > >> In this design, the Provider is responsible for serving the service
> > >> documents.  This means that the service document support will vary
> > >> depending on the capabilities of the Provider implementation.
> > >>
> > >> CollectionAdapters
> > >> ------------------
> > >>
> > >> In each of the three approaches, the same CollectionAdapter interface
> >
> > >> is used.  Also, with the possible exception of URI patterns used for
> > >> links, CollectionAdapters should be independent of the Provider
> > >> implementation used.  We need to find a more elegant way of tying
> > >> Target Resolvers and Collection Adapters together while at the same
> > >> time making it easier to manage links, but that can come later.  The
> > >> more important thing is that once a CollectionAdapter is
> > >> implementation, we should be able to use it regardless of which of
> > the
> > >> three models are selected.
> > >>
> > >> Media Collections
> > >> -----------------
> > >>
> > >> The basic CollectionAdapter interface does not support media
> > >> operations.  If you want to implement support for media collections,
> > >> the CollectionAdapter has to implement the MediaCollectionAdapter
> > >> interface.  The reason for this separation is to reduce the
> > complexity
> > >> of the simplest Atompub implementations that will only ever support
> > >> Atom entries.
> > >>
> > >> Transactional
> > >> -------------
> > >>
> > >> CollectionAdapter implementations can implement the Transactional
> > >> interface if they wish to support transactional start/end/compensate
> > >> semantics.  Provider implementations SHOULD call Transactional.start
> > ()
> > >> before delegating to the CollectionAdapter method and
> > >> Transactional.end() after delegating.  If an error occurs, the
> > >> Provider SHOULD call Transactional.compensate().
> > >>
> > >> - James
> > >
> > >
> >
>
>

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