Hi Cassie, I'm looking out for the API server and was under the
assumption that it would be an autonomous server. After looking at the
changes to the source tree recently (moving from the proposed
/java/social to under /java/gadgets/../social/ it seems that a few
small things have been done to make the API server more dependent on
the gadget server. Maybe this is just a matter of expediency and was
done simply to get a stub checked in to work with. But the concerns of
the PHP dev here are basically my concerns: Java build and deployment
decisions affecting the 'standard' way of doing things.

comments below:

On Tue, Mar 18, 2008 at 8:46 AM, Cassie <[EMAIL PROTECTED]> wrote:
> My thoughts:
>
>  1. We should make the php stuff use the same url structure as the java stuff
>  (making people change configs by hand is evil)
>  2. The java social/* directory depends on the gadgets/* directory.

Can you explain why this is. This seems wrong to me.

>  3. I don't care what the url is at all, as long as people only have to run
>  one server by default for the java stuff.

There are two servers that have not dependencies on one another and
they can be mounted at their own urls or on run on different servers.
I'm a little confused about the need to get a nice 'all in one'
reference implementation server for all of OpenSocial and how it
balances against the need to provide an implementation that is
designed to be deployed in a realistic server environment. The server
as it is now can be dis-assembled and distributed but seems like this
dis-assembly could be facilitated be taking some measures to isolate
the components and add more hooks for application servers.

>
>  Okay, so all of those mean that we either need to make the
>  gadgets/socialdata url work for php or we need to make the /socialdata url
>  for for java.
>
>  Unfortunately, for the java side things work like this:
>  - the entire running server is mapped to localhost:8080/gadgets.
>  - each servlet has a namespace under /gadgets. so the GadgetDataServlet
>  happens to be mapped to socialdata just like the JsServlet is mapped to js
>  and the RpcServlet is mapped to metadata. so social data is at the same
>  level as all the other servlets

This doesn't seem necessary. The social data (the API server for
people, activities and appdata) is not functionally at the same level
as these other servlets because it is not an interface for the gadget
server. You don't need to serve gadgets to participate in OpenSocial.

>  - i don't think i can get out from under the gadgets namespace unless we a)
>  get rid of the namespace altogether or b) start up two servers. both of
>  those don't sound so hot.

I don't see what's wrong with a or b. Where is it specified that all
servers must start with a /gadgets/ url prefix?

>
>  On the php side, i didn't quite get why the socialdata servlet can't live
>  under the gadgets namespace (sorry for my naivete!)
>  Can we just have php/gadgets/index.php handle the socialdata calls? Perhaps
>  it would help if we changed the name from "socialdata" to "gadgetdata". Or
>  just "data"?

I'd hope that people could mix up the runtimes that are serving
different parts the /gadgets and /social system but the spec will be
fairly clear so that there are consistent url patterns across the
servers implemented at different OpenSocial sites.

>
>  If you look in the social directory it actually doesn't have to be just
>  social stuff anymore. It can handle any json request to the server for data.
>  In fact, all the state file calls are handled in addition to the
>  specifically opensocial type of calls. That is why their is now a specific
>  opensocial subdirectory. And, if a different gadget feature needed data from
>  the server then this setup would be reused.
>
>  Alright, so, I'm up for anything that works!
>  Let me know if you understood what I wrote and hopefully we can find an
>  answer.
>
>  Thanks.
>
>  - Cassie
>
>
>
>
>  On Tue, Mar 18, 2008 at 4:30 PM, Chris Chabot <[EMAIL PROTECTED]> wrote:
>
>  > Hey Cassie (I believe your the main author of the social part of shindig
>  > at the moment?),
>  >
>  > I'm getting started on adding some social to the PHP part too, and while
>  > looking at the current work and examples i see that it currently uses
>  > the following url:
>  > http://<host>/gadgets/socialdata
>  >
>  > While you can keep your folders nicely separated in the Java version,
>  > this is more difficult to do in the PHP version (since this URL would
>  > imply the social data part should atleast partially reside in the
>  > gadgets  folder), which creates a dependency and mixing of sources i
>  > would rather prevent.
>  >
>  > Now i could probably bypass this by some .htaccess magic and redirect
>  > the requests based on the URL to the right PHP source folder, but that
>  > would make it less readable and less intuitive for anyone looking at the
>  > PHP source (you would expect /gadgets/* to go to
>  > <shindig_root>/php/gadgets/index.php and forinstance /social/* to go to
>  > <shindig_root>/social/index.php).
>  >
>  > Now it's my intention to keep the PHP version identical to the Java
>  > version in every way possible as far as the examples and basic file
>  > usage goes (features, synd config, urls etc), so this would present a
>  > bit of a dilemma for me, do i create some (relatively ugly) hacks to
>  > make it work with the /gadgets/socialdata or do i break away from the
>  > standard url config and hope that people read the documentation well
>  > enough to see what they should change to make the PHP version work?
>  >
>  > So my hope is we can bypass this by putting the GadgetDataServlet under
>  > a different url (/social/data? or /socialdata/<something> ? or even
>  > just /social[data] ?), would help me a lot :)
>  >
>  >    -- Chris
>  >
>

Reply via email to