+1 for 2, and willing to work on 2 (infact I need to anyway), but
would like to put sufficient abstraction in to make 1,2,3 all work.
and sorry to be confused and a pain, but the code base as of r648723
has PeopleService, ActivitiesService and DataService.... are we
talking about implementing (2),(3) versions of (1) [as listed below]
as it exists now, or , a new impl of the restful API ontop of Abdera
which potentially would not use PeopleService, ActivitiesService and
DataService at all.
Just trying to get the layers clear in my head.
Ian
On 16 Apr 2008, at 18:10, Vasu Nori wrote:
let me put this proposal to vote.
Reference implementation of Opensocial API server (in java) should
provide
backend implementation for
(1) file system
(2) JavaDB
(3) CouchDB
(4) all the above
If you voted for any one of the these, how about volunteering? :)
I can volunteer for (2).
(1) already exists in Shindig. Could use help in adding/deleting/
updating
data. Right now, Shindig already implements SELECT on data.
thanks
On Tue, Apr 15, 2008 at 10:46 PM, Santiago Gala
<[EMAIL PROTECTED]>
wrote:
El mar, 15-04-2008 a las 16:52 -0700, Kevin Brown escribió:
Couldn't SQLite serve the same role?
Of course. SQLite or Derby (embedded in the java server) or any
relational DB with the proper scripts for creation of the demo DB.
I pointed at CouchDB because:
- it has a json on HTTP wire format used with a ReST API, i.e., it
can
be mapped to directly serve what we want here.
- it is programmed using javascript in the server, i.e., quite
natural
for people coding gadgets. (See for instance
http://wiki.apache.org/couchdb/GettingStartedWithJavaScript )
- it is designed as a "new breed" DB, easy to replicate and scale
- they joined incubation close to when shindig did, so they are
"neighbors" :)
- I wanted to be provocative and point to something quite out of the
ordinary
I specifically told about "prototyping", as I was thinking that it
might
be quite useful for someone working on the right interfaces and
formats
to use such a tool. I was thinking about writing a quick snippet
of code
and testing on the fly. I don't think it is the right thing for
production right now, as it might scare people.
Regards
Santiago
On Tue, Apr 15, 2008 at 3:56 PM, Santiago Gala
<[EMAIL PROTECTED]>
wrote:
El mar, 15-04-2008 a las 23:35 +0100, Ian Boston escribió:
I don't know enough about CouchDB to say if its a good
solution, but
am I correct in thinking its another server to setup and wont
run in
the same JVM as the Shindig instance ? (Looking at the svn it
see c
code, and mention of mod_couch ... sounds like it needs apache
httpd
to run ).
It does not. It won't run in the same JVM as Shindig,... because
it is
not java. mod_couch is an erlang module. CouchDB is written in
Erlang
+ C (the javascript interpreter and the glue).
To make it really easy for someone to take a Shindig instance
out of
the box, the approach that Jackrabbit took might be worth
following.
They used a default DB of Derby, which didn't need any config,
as it
will run embedded. This also allowed them to make the TCK run all
its
tests inside maven without additional config.
You are assuming that everybody wants to run java, which is not
something you are so free to assume, specially in this field.
CouchDB
is
a DB that uses json as native wire format and javascript as backend
language, which makes it have an excellent impedance with
shindig as
it
might serve straight from the DB. While it is a very young
project, I
just mentioned its use for prototyping of the social stuff.
This may all be small point, since I see that Abdera has a
number of
other ColectionAdapters including iBatis, Hibernate and even JCR.
--------------
Another quick question.
With the REST api being implemented, is there any point in
implementing the Services (eg PeopleService) that exist in the
current code base against a DB backend .... or will they be
deprecated shortly (within 4 weeks)
Ian
On 15 Apr 2008, at 17:28, Jun Yang (杨骏) wrote:
On Tue, Apr 15, 2008 at 7:30 AM, Santiago Gala
<[EMAIL PROTECTED]>
wrote:
El mar, 15-04-2008 a las 03:59 -0700, Kevin Brown escribió:
On Tue, Apr 15, 2008 at 2:54 AM, Ian Boston <[EMAIL PROTECTED]>
wrote:
Is the intention with the rest based apis for opensocial in
shindig to
just provide the JS client libraries and leave the
implementation of
the
server side of the api to the implementor.
Yes.
or
will Shindig be implementing a rest based server component,
with DB
backend
The first version will come with good support for relational
databases, as
is the common case.
I wonder if using a very simple CouchDB backend could make
sense.
CouchDB offers a DB with native json API and javascript running
in
the
server, so at least propotype support for initial experiments.
Since the server is based on Abdera and Abdera already has an
adapter for
CouchDB, this should be easy.
Jun
It looks a great tool for this, though for a prototype python +
simplejson + some dictionaries can actually be a similar very
simple
framework. Or s/python/<your favorite dynamic language>/ :)
RESTful APIs are in development now, though nothing has been
committed
yet.
See mail archives for discussion. I'd expect the first commit
within the
next week or two at most. The RESTful spec was just finalized
last week
--
we need a little time! :)
Also, is there any intention to use POST on the rest URL's
to do
updates
to
social data where it makes sense... sorry if this has been
mentioned
already.
We'll do whatever the spec requires.
+1, ReST requires POST/PUT for non-idempotent request, and
*updates* are
always non-idempotent. Even if I'm not following the spec right
now, I
would be very surprised if the spec used GET for updates. But
this, as
Kevin said, belongs to the spec ground.
--
Santiago Gala
http://memojo.com/~sgala/blog/ <http://memojo.com/%7Esgala/
blog/><
http://memojo.com/%7Esgala/blog/> <
http://memojo.com/%7Esgala/blog/>
--
Santiago Gala
http://memojo.com/~sgala/blog/ <http://memojo.com/%7Esgala/blog/> <
http://memojo.com/%7Esgala/blog/>
--
Santiago Gala
http://memojo.com/~sgala/blog/ <http://memojo.com/%7Esgala/blog/>
