On Fri, Jul 11, 2008 at 2:34 PM, Chris Chabot <[EMAIL PROTECTED]> wrote: > On Jul 11, 2008, at 10:18 PM, David Primmer wrote: > >> We continually debate what the server >> should look like because we don't have clear leadership in this area. > > Actually imo that is a very good thing, and i think for a big part of what > an apache project is about, decisions are made by the committers (who became > committers based on merit), in a democratic way.. this kind of email is part > of that democratic process, and a Good-Thing (Tm).
I agree. I've probably been writing way more email than people have time to read. ;-) > >> 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. > > I would agree that a flexible implementation is a good thing too, however i > can't follow to far in the 'expressing the potential of the spec'. if there > is to much ambiguity in the spec or implementations this would actually be > very detrimental to Open Social as a whole, it could quickly lead to > applications that only work on one specific platform, and we're all working > very hard to try to prevent that and word towards a 'write once, run > everywhere' situation.. we're some ways of from that still, but that's > something we should be looking to solve and not promote :) So from that > point of view i think having something that isn't to open ended is a good > thing. > > Keep in mind btw not all SNS's will use shindig, so everyone following the > same spec is rather crucial > > >> The server cannot be so flexible that it makes the process of setting >> it up to implement the spec prone to errors. > > Why should there be a 'setting it up to spec' at all? Setting up shindig > should be as simple as 'write the data service layer and your done', in my > opinion, so I'm not a 100% sure what you mean with 'setting it up to spec', > except that it does make me worry about having different social network > sites that all work differently, which to repeat my self is the opposite of > what we are trying to accomplish :) > >> 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. > > I think that is rather uncalled for. The spec is decided on the (very open) > gadget-and-opensocial-spec list, where all parties involved can vote and > propose and discuss how they feel the way the spec should move forward and > what should be changed, this includes parties from all sorts and sizes and i > never ever got the impression that in any way this was run in an exclusive > fashion where people were not looking out for the future SNS's. I'm not sure what you you're saying is uncalled for. We both said the same thing in my reading. I agree with everything you've said here, but I never mentioned the spec in that paragraph. I simply said that the server design is being driven by the people contributing to it. Those people are using the server as well. I don't see what's disagreeable about pointing out that there are real-world forces shaping it. > > So i think your trying to say that by not being flexible enough in how > shindig can be used, we might disadvantage future SNS's ? Then there's a > different process to follow that 'forcing the issue in shindig', write a > proposal to the spec list to how you see it should be made more flexible, > and if that proposal is carried, shindig will implement it. > > There's a lot of flexibility build into shindig already to be able to > support containers of any type, but that flexibility is expressed explicitly > in the spec, the way it should be ? > >>> 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. > > > You have expressed your worries about this before, the ability of the #2 > code base to be able to implement 'more complex tasks like Atom Pub', > however i never got such signals from Cassie in her emails about either > implementations. > > What is the basis of these worries? If you could please explain them instead > of making an absolute statement (not "that wont work", but instead explain > why it wont work) you could probably very easily convince everyone here to > why the abdera implementation is superior for these issues that apparently a > lot of people are currently missing, or have your own worries addressed in a > satisfactory manner. > I've posted quite a few long emails to this list and the spec asking these questions and had very few substantive replies. I also don't think I've been making absolute statements as you claim and I'm sorry I've given you that impression. There doesn't seem to be much serious interest in implementing rfc 5023 and 4287 and so that's why I suggested maybe we not have such a strict requirement on it or have it be so prominent in the spec. The spec never says "this is an atom rfc-compliant service", but instead says stuff like "use an AtomPub POST" or "use AtomPub optimistic concurrency" so maybe I was just extrapolating too far. Maybe to others, I'm splitting hairs, but I think there's a big difference between supporting atom pub and supporting some newly-defined restful service that has xml and json payload, but I don't feel it's a good use of m time writing long explanations of the differences. There are rfc's that do that. > i also remeber an earlier discussion about this same subject where (i think > it was fargo?) said that atom should just be another expression of the same > internal data structure and it might as well be output in a CSV format, to > which you also responded that things weren't that simple ... so you must > have some background to this opinion, that leads you to another conclusion? > It would help a lot if you could give your reasoning is less general and > more specific terms. > > -- Chris >
