I dont say that changing the Abdera's code would be impossible, but if for example i found a bug in Abdera, and it has to be changed, i have to submit first the patch to Abdera's project, then wait for Shindig to have the new dependency or update it, change the code in Shindig to comply with the fix, and then we have our Shindig updated, that is hard work to do, dont you think?, its just my opinion.
G.- On Fri, Jul 11, 2008 at 5:18 PM, David Primmer <[EMAIL PROTECTED]> wrote: > On Fri, Jul 11, 2008 at 8:47 AM, Ian Boston <[EMAIL PROTECTED]> wrote: > > Cassie, > > Although I think flexible frameworks like Abdera are great for complex > > applications where the effort of coding make using the framework > worthwhile, > > I also believe that if the task is focused, and the scope known then > often > > direct implementation is a more sustainable route. > > I think this is the right way to look at it. There are always going to > be dependencies in software and you need to asses the trade-offs. I > don't think Gonzalo's point earlier about not being able to change > code in Abdera fast enough is valid. > > So I want to ask again the questions you seem sure about: is the task > is focused and is the scope is known? I don't think just saying we > have a written spec doc means the scope is known. What is the 'task' > of shindig? This seems like a 'product design' decision, as shindig > ends up being something like a product. It's got an intended audience > and they have different needs. We continually debate what the server > should look like because we don't have clear leadership in this area. > > Some people will take issue with the idea that the server should only > do what is in the spec in a fairly straightforward and hardcoded way. > If you look at the spec, including the atom and the oauth specs that > it references, you will find that there is no concrete implementation > laid out. There are lot of suggestions and some examples. The process > of writing shindig api server has always been about making decisions > that are not made in the spec. Do you want a highly opinionated server > or one that is more open-ended, expressing the potential of the spec? > These questions are continually debated and I don't think they're > resolved. > > The server cannot be so flexible that it makes the process of setting > it up to implement the spec prone to errors. I think at this point, > the people with a stake in how the server is designed are the people > who are turning around and serving data with it at their companies. > We're all, I assume, trying to look out for those in the future who > might want to use shindig as a basis for their own SNS or other site. > > > The scope of Shindig is focused to the OpenSocial API, and so IMHO 2 is > the > > right approach. > > I haven't seen an argument as to how #2 is actually more focused on > the OpenSocial API other than that it's better because there's less > code to read and understand. Really, this is the jist of most of the > arguments for it and while it's nominally true, it doesn't hold water. > I agree that it's easier to read 1 or 2 files and see the whole > codepath but I don't think #2 can stay that way for very long. It's > just not going to look anything like that when it has to start doing > more complex tasks to support Atom Pub and the field hoisting > operations in the spec. > > Frankly, I don't like #2 because it's a funky combo of a REST and RPC > interface with lots of shortcuts that make it way more on the RPC side > of things. Look at the code, and look at the Abdera-based code that I > implemented that works exactly the same way in the same number of > lines. #2 is doing some not so easy to understand url processing in an > attempt to treat path segments of the urls as request parameters. > Think about extending this model. > > I'll gladly follow the folks down the path of 'less code is better'. > When you go from the perspective of what's the dead simplest thing to > code up, Why bother with the urls? Why bother with HTTP semantics? > Assuming all the code for processing a request is in stored procedures > in your db (or at Google bouncing around inside the datacenters) so > why go through the REST shenanigans in the first place? You can > probably write a single JSON-RPC batching endpoint in one file that > just passes everything through to your 'real server'. So why not just > do that? Less code in Shindig, more code in your private system. > > Instead of arguing about frameworks, we should be discussing whether > the same codebase should support AtomPub and if we need to add a > special RPC-only, non-HTTPy server to the spec and un-shackle the > JSON-RPC style programmers from the RESTful API server requirements. > We should also have a real discussion of what common elements are > necessary in all modern web server apps and re-use the stuff we have > in common. > > > > > The only question in my mind is where those who might take Shindig want > to > > add more complex REST functionality and would like Abdera to be used. > > However, in this case, not using Abdera in Shindig leaves those > implementors > > free to chose the version of Abdera they want for their own > implementation. > > It would be a bad thing if Shindig bound to Abdera and forced others to > use > > that version. > > > > I have an example, Alfresco a JSR-170 implementation binds to a specific > > version of Hibernate, that make it impossible to embed into other > > applications that bind to a different version of Hibernate. > > The latest approach I tried to take with the Abdera-based JSON > processing code is to show how you could keep Abdera's servlet, > request context object and url routing and generation system and > support a very simple java servlet web programming model. The > difference in the two approaches for JSON requests is how urls and > parameters are handled. The handlers in #2 even have the same levels > of abstraction, one parent class that manages HTTP and one child that > manages model interaction. I haven't seen any discussion of that. The > same HTTP base can be used when people want to do Atom processing and > it can share a lot of the same basic server code. > > > > > So for these reasons, not biding to Abdera, makes it easier for others to > > use Abdera where appropriate, hence > > > > 2. > > Abdera is most appropriate when you need to easily enforce atom pub / > synd compliance. At what point will this be optional to the API > server? There's a lot of stuff in Abdera that you can use if you agree > that this is not optional. What is 'binding'? Using the Atom object > model? Using the request object? Using the routing system? > > > > > Ian > > On 11 Jul 2008, at 15:16, Gonzalo Aune wrote: > > > >> Cassie, > >> > >> I think that the option 2 would be better, mainly because the Abdera is > >> another project, and if we have to change some code in the future, doing > >> it > >> in the DataService would be much faster than changing code in Abdera, > and > >> then update the shindig project, plus that as Chris says, in the PHP > >> version > >> we use something similar to the option 2 and its more portable between > the > >> 2 > >> versions =) > >> > >> G.- > >> > >> On Fri, Jul 11, 2008 at 11:07 AM, Chris Chabot <[EMAIL PROTECTED]> > wrote: > >> > >>> Hey Cassie, > >>> > >>> Now i don't think my opinion should be a binding vote, but i do have a > >>> strong preference for the DataService based one (option #2). > >>> > >>> My main reason for that is that when i was looking at both code bases > (as > >>> a > >>> non java expert) the Abdera code base was incredibly tough to get into, > >>> and > >>> see what it actually -did-, it seemed very fragmented and hard to trace > >>> through; However the DataService based code was easy to follow and > >>> understand. > >>> > >>> Now this probably isn't a incredibly crucial fact for anyone who's used > >>> to > >>> Abdera's structure's, however for future contributers, and from an > >>> anyone-should-be-able-to-maintain-and-modify-this perspective, the > >>> readability of it does play an important factor and from my perspective > >>> solution #2 does this right where as #1 makes this a bit harder. > >>> > >>> We're an infrastructure type of project so i'm not going to argue all > >>> code > >>> should be simple or easy to understand or maintain, infrastructure work > >>> always comes with it's complexities; However if there's no other strong > >>> factors making one solution superior over the other, there's no reason > >>> either to make it harder then it should be :) > >>> > >>> Also, and again this shouldn't be a binding reason, the PHP version of > >>> shindig uses a structure that is very close to the #2 solution, so that > >>> makes knowledge portable between the 2 versions, which can be quite > >>> beneficial in a few situations (and promotes mind share between the 2 > >>> versions) so from that perspective i'm also pro #2. > >>> > >>> Anyhow that's my $0.02 > >>> > >>> -- Chris > >>> > >>> > >>> On Jul 8, 2008, at 11:34 PM, Cassie wrote: > >>> > >>> Hello Shindig friends - > >>>> > >>>> As I'm sure most have you have picked up at least somewhat, there are > >>>> two > >>>> main implementations of the RESTful opensocial spec within the java > >>>> Shindig. > >>>> They are both complete enough to give a good idea of what a finished > >>>> implementation would look like which means that we should really > decide > >>>> on > >>>> one impl to focus on. So, I am starting this thread in the hopes that > we > >>>> can > >>>> objectively evaluate both options and come to a consensus on which one > >>>> we > >>>> should follow through with. > >>>> > >>>> It would be great to get everybody thinking along the same lines so > that > >>>> we > >>>> can finish implementing the restful spec and get that much closer to > >>>> full > >>>> 0.8 support! > >>>> > >>>> Here is a brief outline of the two java options: > >>>> > >>>> > >>>> 1. Implementation based on abdera. > >>>> Most code is located in the shindig.social.abdera package. > >>>> > >>>> Note: When evaluating look at the PersonJsonAdapter and PersonAdapter > >>>> implementations as they are the most updated. (as opposed to > activities > >>>> and > >>>> appdata) > >>>> > >>>> - shindig/social/RestServerServlet handles all requests > >>>> - the SocialRouteManager sets up the mapping from url and format (json > >>>> vs > >>>> atom) to the right adapter > >>>> - the adapters (6 total, 3 in the atom folder, 3 in the json folder) > get > >>>> the > >>>> data from the corresponding social services. > >>>> - the atom adapters use abdera to translate the response into proper > >>>> atom > >>>> format > >>>> - the json adapters use the JSONFilter and SimpleJsonAdapter (which > uses > >>>> the > >>>> beanJsonConveter) to talk the proper json format on input and output > >>>> > >>>> > >>>> 2. "DataService" (similar to the old wire format GadgetDataServlet) > >>>> Most code is located in the shindig.social.dataservice package. > >>>> > >>>> - DataServiceServlet handles all requests and dispatches to > >>>> ActivityHandler, > >>>> AppDataHandler, PersonHandler which are injected in a url to class > guice > >>>> map. > >>>> - The three handlers translate from the url pattern to the > corresponding > >>>> social services. > >>>> - The handlers all return Futures so that all data fetches get > executed > >>>> at > >>>> the same time can then be batched. > >>>> - The DataServiceServlet (via the beanJson and beanXml converters) > >>>> handles > >>>> the translation from java to xml or json. > >>>> - The xml format is not yet spec compliant - it needs to be more > atomy. > >>>> this > >>>> code would go inside the beanXmlConverter class > >>>> > >>>> > >>>> > >>>> Alright, so the code is all in the java/social-api section of the > trunk. > >>>> Please look around and comment on the pros and cons of each set of > code. > >>>> (and note, there are definitely still todos and ugliness in both > >>>> packages.. > >>>> they are prob both around 80% complete) > >>>> > >>>> And if anybody has a better idea for figuring out how to get us all on > >>>> one > >>>> code path for the java restful impl I'm all ears! > >>>> Thanks. > >>>> > >>>> - Cassie > >>>> > >>> > >>> > > > > >
