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).
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.
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 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
