Ok, cool, much clearer now, thanks.
I will generate something for the DB impl., in the next 24-48h.
Ian
On 16 Apr 2008, at 18:44, Vasu Nori wrote:
On Wed, Apr 16, 2008 at 10:25 AM, Ian Boston <[EMAIL PROTECTED]> wrote:
+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.
you are it for JavaDB impl
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.
sorry, I wasn't clear. let me explain. (this is about java
implmentation.
not sure if it will be directly applicable to php/any other lang)
I am talking about enhancing the current interfaces in
org.apache.shindig.social.opensocial package for People/Activities/
Data to
handle RESTful API.
Right now, shindig implementation has an impl class
XmlStateFileFetcher.java
to READ (xml file with data) from a filesystem. It reads data to
fulfill
various RETRIEVE requests for People/Activities/Data.
To implement backend for RESTful API,
The interfaces in org.apache.shindig.social.opensocial package are
to be
enhanced to include methods to Retrieve a single entity for the given
criteria, Insert/Update/Delete a single entity. (Signatures for these
methods are not completely defined yet. but hopefully within a week)
and then implement the following
1. *Filesystem *impl ( needs augmenting the current
XmlStateFileFetcher.java to handle Insert/Update/Delete to
correspond with
Post/Put/Delete Restful operations, respectively.
2. For *JavaDB and CouchDB*, we need NEW impl classes to handle
Select/Insert/Update/Delete. Select can be a single entity (for
RESTful API)
or it can return 0 or more entities (to correspond with the current
social-api in Shindig).
hope it is clearer now..
thanks
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/> <
http://memojo.com/%7Esgala/blog/>
--
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/>
