On Thu, Mar 27, 2008 at 11:50 AM, David Primmer <[EMAIL PROTECTED]> wrote:
> I'll just start asking questions just to see what people are thinking. > These questions are all server related. I don't intend to go into any > details of the wire protocols so if you're only interested in that, > you can ignore this. This also assumes an Abdera java implementation. > I'd rather not endlessly cross-post to the abdera lists so I'll just > send one brief message over there pointing people to this post and be > done with it. > > What are our deployment scenarios? How 'monolithic' should the server > be, like should it do all dispatching or have a replaceable dispatch > system? Build a server that multiple domains could be hosted on? I'm > leaning toward keeping the server simple, but not making a toy. For the gadget server, we've been favoring an interface-heavy design which allows for implementations to be either monolithic (what our default implementations of most of the interfaces do, for simplicity), or modular (how many of the deployments ultimately work in real production environments). Mostly this is a question of scale. What constitutes an adequate component for a small site is never going to be sufficient for a large site, and what a large site needs is usually far too complex for the small site. Abdera is a REST framework that uses ATOM conventions. It has a lot of > basic features you'd find in any webserver framework, like helpers for > generating error codes and such. The developers have been careful to > make sure that it is not tied to one serialization system, but I'd > assume we'd use the new StreamWriter and design a custom JSON writer. > > How does the CollectionAdapter idea fit in the server? We'll be > producing three different wire formats that can be generated in JSON > or XML and could be connected to any number of backends. How do these > fit on to ATOM's workspace and service concepts? I'd say that we'd > need three workspaces: people, activities and appdata. These will have > multiple collections in them. Would they all use the same Adapter type > that produces the backend interface for storage? > > And what about making a separate servlet for each of people, > activities and appdata? This might be easier for fitting into existing > systems that have already started writing api servers, but it's not as > simple for someone starting from scratch. I'd say just use one > Provider. > > Here are some specific technologies in Abera that might be useful: > > The internal Abdera Filter system (that works like java servlet filter > chaining) as an output filter to allow the json/xml output decision to > be made late or early in the processing and standardize the rest of > the request processing. After thinking about this, it's probably not > going to be applicable, but there may be other uses for Abdera > filters. > > Using the new, fairly experimental RouteManager system that James has > ported from rails (makes generating urls much easier) instead of the > StructuredTargetResolver. > > Abdera has an OAuth client. Do we want to add an OAuth server? I'd really like to make sure that all the OAuth related stuff is shared (where it makes sense) between the gadget rendering component and the RESTful API component. Most containers are going to approach all of these pieces as a single solution, and we should go out of our way to make sure that we have consistency between components. > > quick server impl guides: > > http://cwiki.apache.org/confluence/download/attachments/69763/abderaserverguide.pdf > > http://cwiki.apache.org/confluence/display/ABDERA/Your+first+AtomPub+Server > > davep > -- ~Kevin
