some initial questions about the shindig gateway api server

[David Primmer <da...@gmail.com>]

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.

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?

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

Re: some initial questions about the shindig gateway api server

[James M Snell <ja...@gmail.com>]

David Primmer wrote:
> [snip]
> 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.
> 

This can be handled in a couple of ways.  Every CollectionAdapter method 
returns a ResponseContext object that is responsible for serializing the 
response.  Filters can modify the ResponseContext in a variety of ways 
and the serialization is always done as late as possible.

Shindig can choose to implement Filters that produce the correct output; 
or, alternatively can choose to implement custom ResponseContext 
implementations, or can use things like the existing 
StreamWriterResponseContext object, or any combination of options.

> Using the new, fairly experimental RouteManager system that James has
> ported from rails (makes generating urls much easier) instead of the
> StructuredTargetResolver.
> 

As a quick note: it is a partial port; not all of the capabilities of 
the rails route mechanism are supported.

- James

> Abdera has an OAuth client. Do we want to add an OAuth server?
> 
> 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
> 

Re: some initial questions about the shindig gateway api server

[Kevin Brown <et...@google.com>]

On Thu, Mar 27, 2008 at 11:50 AM, David Primmer <da...@gmail.com>
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