You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Chris Chabot <ch...@xs4all.nl> on 2008/03/18 16:30:25 UTC
Social data request URL issue
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
RE: Social data request URL issue
Posted by Chris Chabot <ch...@xs4all.nl>.
While this is seriously cool stuff (and it does look like it is), I do see a
few snags with this kind of setup:
- Most people using the PHP code will have an existing infrastructure (most
likely apache, sometimes lighthttp etc) and do not want to run Jetty next to
it and take on a whole new chain to maintain.
- This looks like it runs PHP as a CGI .. slow being the keyword here (and
presumable also completely missing out on most of the php accelerating
possibilities such as ZendPlatform or APC)
- It wouldn't solve the issue that we want the URL's to be the same between
the Java and PHP versions, instead of creating 2 different ones (like you
suggested: /foo and foojava forinstance) so that all the examples and
javascripts work out of the box for both versions without any hacking to the
source.
So while indeed really cool stuff, it doesn't really look like a solution to
me at the moment
-- Chris
-----Original Message-----
From: Alejandro Rivero [mailto:al.rivero@gmail.com]
Sent: Tuesday, March 18, 2008 21:25
To: shindig-dev@incubator.apache.org
Subject: Re: Social data request URL issue
2008/3/18, Alejandro Rivero <al...@gmail.com>:
>
>
>
> so you can just rename the urlpattern socialdata to socialdatajava and
redirect the rest to a php service; I do not know yet how it works in
maven-jetty
Hmm not straightforward but it is described here.
http://docs.codehaus.org/display/JETTY/Jetty+and+PHP
Re: Social data request URL issue
Posted by Alejandro Rivero <al...@gmail.com>.
2008/3/18, Alejandro Rivero <al...@gmail.com>:
>
>
>
> so you can just rename the urlpattern socialdata to socialdatajava and redirect the rest to a php service; I do not know yet how it works in maven-jetty
Hmm not straightforward but it is described here.
http://docs.codehaus.org/display/JETTY/Jetty+and+PHP
Re: Social data request URL issue
Posted by Alejandro Rivero <al...@gmail.com>.
2008/3/18, Chris Chabot <ch...@xs4all.nl>:
>
>
> So an alternative is to do some .htaccess magic (pointing
> the /gadgets/social data request to a different directory/index.php then
> the other requests), but that wouldn't really be a self documenting
> solution and rely on people having some rudimentary mod_rewrite
> knowledge to customize anything, so while it has a lot less impact then
> the above it still adds an extra hurdle to the deployment other what i
> think the most basic PHP users would expect. (they would assume they can
> just upload some files to a folder, and it should 'work').
>
> So indeed the option i would be left with is to build the social data
> part into the gadget server, and have it just be another event handler
> in the same source tree and restructure the directory layout a bit to
> make it more clear what is what, ie:
>
> /php/gadgets/index.php (entry point for everything)
in the same source tree?
Hmm, let me see the code. Actually, Cassie has implemented already two
handlers:
handlers.add(new OpenSocialDataHandler());
handlers.add(new StateFileDataHandler());
in theory, it could be possible to implement a PhpBridgeDataHandler()
reading the query to a xxx.xxx/index.php, very in the same way that
StateFileDataHandler reads an static xml thing.
> Well... thankfully the Java stuff is still easy to separate.
It seems also reasonable to separate the whole /gadgets/social json request
when it hits jetty. I understand this hit is described in
shindig/java/gadgets/src/main/webapp/WEB-INF/web.xml
<servlet>
<servlet-name>socialdata</servlet-name>
<servlet-class>
org.apache.shindig.social.GadgetDataServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>socialdata</servlet-name>
<url-pattern>/socialdata</url-pattern>
</servlet-mapping>
so you can just rename the urlpattern socialdata to socialdatajava and
redirect the rest to a php service; I do not know yet how it works in
maven-jetty but it should be some tag in this file; it is only that it is
not compiling just now, because I am using java 1.4.5 and Cassie has
migrated already to use jdk6. (Has it been announced somewhere???)
Alejandro
Re: Social data request URL issue
Posted by Chris Chabot <ch...@xs4all.nl>.
Well relatively easy is a tricky word in PHP land since the target
audience varies from the person who knows how to 'ftp' some files to his
server, without even knowing what 'shell access might be, to the real
die hard PHP techies who could pull things apart in more ways then we
could imagine :)
That being said, PHP doesn't offer any kind of deployment or building
infrastructure of any kind, other then the creative use of mkdir, cp or
mv commands :)
So if i really integrate the code of both the social and gadget server
into one entry point you would have to copy that twice into different
directories, and from both remove the folders and files that are
irrelevant there, and edit the entry point (index.php) to only have the
logic for the gadget or social server ... not something you could easily
do without some basic knowledge of how the PHP code works, and with huge
downsides to how easy it is to follow releases / svn. So that's not
really a good option unfortunately.
So an alternative is to do some .htaccess magic (pointing
the /gadgets/social data request to a different directory/index.php then
the other requests), but that wouldn't really be a self documenting
solution and rely on people having some rudimentary mod_rewrite
knowledge to customize anything, so while it has a lot less impact then
the above it still adds an extra hurdle to the deployment other what i
think the most basic PHP users would expect. (they would assume they can
just upload some files to a folder, and it should 'work').
So indeed the option i would be left with is to build the social data
part into the gadget server, and have it just be another event handler
in the same source tree and restructure the directory layout a bit to
make it more clear what is what, ie:
/php/gadgets/index.php (entry point for everything)
/php/gadgets/http/*.php (all the event handlers for both gadget server,
rpc, proxy, social data)
/php/gadgets/gadgetServer/*.php (php files related to the gadget server
part)
/php/gadgets/socialServer/*.php (files related to the social data)
... etc...
And then possibly add a configuration if you want 'this' server to do
only gadget rendering / js / rpc / proxy or only social data, or both
(being the default). Not the prettiest solution but workable i guess :)
I think my preference i still to really split out the gadgets and social
'name spaces' to prevent confusion, but i guess that's not possible
while satisfying both the java and php land situations
-- Chris
On Tue, 2008-03-18 at 17:57 +0100, Cassie wrote:
> Well... thankfully the Java stuff is still easy to separate. So, if you did
> want to use two servers then it wouldn't be too bad. Essentially, you would
> just install the servlet in some other web server somewhere (because
> servlets can be moved around easily) Then, you would just have to do some
> url mapping to have the social server live on a sub path of the gadget
> server (for the same-domain xhr issues)
>
> So, it is relatively easy in java land still.
> (As in the java side would require small file changes as well as a url
> subpath setup)
> (I'm not sure anyone would want to do this as the interfaces in
> social/opensocial/*service could be handled by making remote calls to other
> servers, but I suppose someone might.)
>
> If you build them together in the php land is it still -relatively- easy to
> pull them apart? Is there any way to make it easy while still having them
> live as one url path in php?
>
> - Cassie
>
>
> On Tue, Mar 18, 2008 at 5:48 PM, Chris Chabot <ch...@xs4all.nl> wrote:
>
> > Well my reasoning was based on the assumption (and you know what they
> > say about assumptions) that these could be possible use-cases for the
> > PHP version, where the site its self is likely to be PHP based as well.
> >
> > The assumption being that often the social data server and the gadget
> > server would be run separated from each other.
> >
> > I imagined something like:
> >
> > In a medium sized setup you could have your site run on a few servers,
> > and already have the infrastructure in place for some type of scalable
> > data back-end. The easiest route to add the shindig server to this setup
> > would be by setting up a gadget server (or a couple of them if the scale
> > requires), and add the social data server on the existing site servers
> > (integrating it with the existing data back-end for its social
> > information), this way the infrastructural change would be kept to a
> > minimum and you would re-use it as much as possible. So you would deploy
> > the social data server on the existing site servers,
> >
> > In smaller scenario's where you would for instance only have one server,
> > you would probably want to have 3 vhost's on the same server, one for
> > the gadget server, one for the site and one for the social data server,
> > where you just deploy the source of each into a folder, add your own
> > back-end to the social data server, and you should be done and ready to
> > socialize :)
> >
> > Now the scenario your giving me for the java server is quite different
> > from this, it means all servers involved are both social data and gadget
> > server, in which case the bundling of the two is no problem of course.
> > So the cases i head in my head are just quite different and hence what i
> > expected too :)
> >
> > If we are sure we always want the social data and gadget server running
> > on the same domain / host / server's, then I have no problem adding the
> > social data to the current gadget server code in the PHP version, if
> > that's not the case, then we'll have to start thinking solutions :)
> >
> > -- Chris
> >
> > On Tue, 2008-03-18 at 16:46 +0100, Cassie 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.
> > > 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.
> > >
> > > 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
> > > - 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.
> > >
> > > 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"?
> > >
> > > 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 <ch...@xs4all.nl> 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
> > > >
> >
Re: Social data request URL issue
Posted by Cassie <do...@apache.org>.
Well... thankfully the Java stuff is still easy to separate. So, if you did
want to use two servers then it wouldn't be too bad. Essentially, you would
just install the servlet in some other web server somewhere (because
servlets can be moved around easily) Then, you would just have to do some
url mapping to have the social server live on a sub path of the gadget
server (for the same-domain xhr issues)
So, it is relatively easy in java land still.
(As in the java side would require small file changes as well as a url
subpath setup)
(I'm not sure anyone would want to do this as the interfaces in
social/opensocial/*service could be handled by making remote calls to other
servers, but I suppose someone might.)
If you build them together in the php land is it still -relatively- easy to
pull them apart? Is there any way to make it easy while still having them
live as one url path in php?
- Cassie
On Tue, Mar 18, 2008 at 5:48 PM, Chris Chabot <ch...@xs4all.nl> wrote:
> Well my reasoning was based on the assumption (and you know what they
> say about assumptions) that these could be possible use-cases for the
> PHP version, where the site its self is likely to be PHP based as well.
>
> The assumption being that often the social data server and the gadget
> server would be run separated from each other.
>
> I imagined something like:
>
> In a medium sized setup you could have your site run on a few servers,
> and already have the infrastructure in place for some type of scalable
> data back-end. The easiest route to add the shindig server to this setup
> would be by setting up a gadget server (or a couple of them if the scale
> requires), and add the social data server on the existing site servers
> (integrating it with the existing data back-end for its social
> information), this way the infrastructural change would be kept to a
> minimum and you would re-use it as much as possible. So you would deploy
> the social data server on the existing site servers,
>
> In smaller scenario's where you would for instance only have one server,
> you would probably want to have 3 vhost's on the same server, one for
> the gadget server, one for the site and one for the social data server,
> where you just deploy the source of each into a folder, add your own
> back-end to the social data server, and you should be done and ready to
> socialize :)
>
> Now the scenario your giving me for the java server is quite different
> from this, it means all servers involved are both social data and gadget
> server, in which case the bundling of the two is no problem of course.
> So the cases i head in my head are just quite different and hence what i
> expected too :)
>
> If we are sure we always want the social data and gadget server running
> on the same domain / host / server's, then I have no problem adding the
> social data to the current gadget server code in the PHP version, if
> that's not the case, then we'll have to start thinking solutions :)
>
> -- Chris
>
> On Tue, 2008-03-18 at 16:46 +0100, Cassie 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.
> > 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.
> >
> > 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
> > - 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.
> >
> > 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"?
> >
> > 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 <ch...@xs4all.nl> 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
> > >
>
Re: Social data request URL issue
Posted by Chris Chabot <ch...@xs4all.nl>.
Well my reasoning was based on the assumption (and you know what they
say about assumptions) that these could be possible use-cases for the
PHP version, where the site its self is likely to be PHP based as well.
The assumption being that often the social data server and the gadget
server would be run separated from each other.
I imagined something like:
In a medium sized setup you could have your site run on a few servers,
and already have the infrastructure in place for some type of scalable
data back-end. The easiest route to add the shindig server to this setup
would be by setting up a gadget server (or a couple of them if the scale
requires), and add the social data server on the existing site servers
(integrating it with the existing data back-end for its social
information), this way the infrastructural change would be kept to a
minimum and you would re-use it as much as possible. So you would deploy
the social data server on the existing site servers,
In smaller scenario's where you would for instance only have one server,
you would probably want to have 3 vhost's on the same server, one for
the gadget server, one for the site and one for the social data server,
where you just deploy the source of each into a folder, add your own
back-end to the social data server, and you should be done and ready to
socialize :)
Now the scenario your giving me for the java server is quite different
from this, it means all servers involved are both social data and gadget
server, in which case the bundling of the two is no problem of course.
So the cases i head in my head are just quite different and hence what i
expected too :)
If we are sure we always want the social data and gadget server running
on the same domain / host / server's, then I have no problem adding the
social data to the current gadget server code in the PHP version, if
that's not the case, then we'll have to start thinking solutions :)
-- Chris
On Tue, 2008-03-18 at 16:46 +0100, Cassie 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.
> 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.
>
> 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
> - 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.
>
> 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"?
>
> 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 <ch...@xs4all.nl> 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
> >
Re: Social data request URL issue
Posted by Cassie <do...@apache.org>.
On Thu, Apr 3, 2008 at 3:08 AM, David Primmer <da...@gmail.com> wrote:
> 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
Really quick - the code was never under java/social, it was always
under java/gadgets/.../social.
> 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 <do...@apache.org> 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 <ch...@xs4all.nl> 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
> > >
> >
>
Re: Social data request URL issue
Posted by Vasudeva Nori <va...@gmail.com>.
On undefined, Nick Lothian <nl...@educationau.edu.au> wrote:
> >> 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.
>
> > Yes you do. You can't support opensocial without supporting the gadgets
> spec
> > as well. They're effectively a single spec, although there's currently a
> >pedantic separation due to the way that the specs have evolved.
>
> This is true but perhaps it shouldn't be.
>
> For a variety of reasons we aren't overly interested in the ability of
> users to deploy Gadgets themselves at the moment and we already use other
> technologies for integrating the UIs of applications.
>
> However, a standard way of manipulating the social interactions of users
> and integrating those interactions across applications on the serverside is
> something that interests us greatly.
>
> That means we are much more interested in a standalone API server than one
> integrated into a gadget server - the gadget stuff is something we just
> don't want to have to worry about at the moment.
>
I suspect this could be a pretty common case. A variety of UI tools and
desktop applications can immediately start integrating with
the API Server and consume the data, without actually implementing gadgets.
But is there any TECHNICAL reason why the gadget server and API server
should be tightly coupled in this manner?
could someone elaborate on that please?
thanks
> Nick
>
>
> IMPORTANT: This e-mail, including any attachments, may contain private or
> confidential information. If you think you may not be the intended
> recipient, or if you have received this e-mail in error, please contact the
> sender immediately and delete all copies of this e-mail. If you are not the
> intended recipient, you must not reproduce any part of this e-mail or
> disclose its contents to any other party. This email represents the views of
> the individual sender, which do not necessarily reflect those of
> education.au limited except where the sender expressly states otherwise.
> It is your responsibility to scan this email and any files transmitted with
> it for viruses or any other defects. education.au limited will not be
> liable for any loss, damage or consequence caused directly or indirectly by
> this email.
>
RE: Social data request URL issue
Posted by Nick Lothian <nl...@educationau.edu.au>.
>> 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.
> Yes you do. You can't support opensocial without supporting the gadgets spec
> as well. They're effectively a single spec, although there's currently a
>pedantic separation due to the way that the specs have evolved.
This is true but perhaps it shouldn't be.
For a variety of reasons we aren't overly interested in the ability of users to deploy Gadgets themselves at the moment and we already use other technologies for integrating the UIs of applications.
However, a standard way of manipulating the social interactions of users and integrating those interactions across applications on the serverside is something that interests us greatly.
That means we are much more interested in a standalone API server than one integrated into a gadget server - the gadget stuff is something we just don't want to have to worry about at the moment.
Nick
IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of education.au limited except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.
Re: Social data request URL issue
Posted by Vasudeva Nori <va...@gmail.com>.
On Wed, Apr 2, 2008 at 9:12 PM, Kevin Brown <et...@google.com> wrote:
> On Wed, Apr 2, 2008 at 9:00 PM, Brian Eaton <be...@google.com> wrote:
>
> > On Wed, Apr 2, 2008 at 8:07 PM, John Panzer <jp...@google.com> wrote:
> > <snip>
> > > All of these benefit from separating the code and URLs of the two
> > > subsystems.
> > <snip>
> >
> > Can we please not separate the code too much? There's a certain
> > amount of infrastructure that can be usefully shared between the two
> > services.
> >
>
> I suspect that the best approach here is going to have a separate sub
> project for the shared code (under java/shared or perhaps java/social).
> Both
> java/gadgets and java/api (or whatever name is appropriate) would consume
> the various shared pieces here. The other language ports can follow a
> similar convention using an appropriate structure for their platform.
>
> I originally encouraged Cassie to check the code into a setup like that,
> but
> she had some reasons that now escape me for not doing it then. I think it
> had something to do with not wanting to run a separate server.
Both systems can still run on the same server. It really doesn't matter
whether it is one server or two different servers.
In java land, they can be so separate at run-time that they can run as two
separate applications (ear or war files) even if they are deployed on the
same app server or servlet container, even though they share some code.
Re: Social data request URL issue
Posted by Kevin Brown <et...@google.com>.
On Wed, Apr 2, 2008 at 9:00 PM, Brian Eaton <be...@google.com> wrote:
> On Wed, Apr 2, 2008 at 8:07 PM, John Panzer <jp...@google.com> wrote:
> <snip>
> > All of these benefit from separating the code and URLs of the two
> > subsystems.
> <snip>
>
> Can we please not separate the code too much? There's a certain
> amount of infrastructure that can be usefully shared between the two
> services.
>
I suspect that the best approach here is going to have a separate sub
project for the shared code (under java/shared or perhaps java/social). Both
java/gadgets and java/api (or whatever name is appropriate) would consume
the various shared pieces here. The other language ports can follow a
similar convention using an appropriate structure for their platform.
I originally encouraged Cassie to check the code into a setup like that, but
she had some reasons that now escape me for not doing it then. I think it
had something to do with not wanting to run a separate server.
Re: Social data request URL issue
Posted by Cassie <do...@google.com>.
Now isn't this what I just said?
We are in complete agreement :)
On Thu, Apr 3, 2008 at 11:48 AM, Kevin Brown <et...@google.com> wrote:
>
> On Thu, Apr 3, 2008 at 2:27 AM, Cassie <do...@apache.org> wrote:
>
> > My my - quite a thread happened while I was sleeping. There were like
> > 20 million things that came up, so let me try to address some of them.
> >
> > 1. For complying to the opensocial spec you -must- be able to render
> > and correctly display gadgets. Opensocial the spec relies on the
> > gadget spec. There is dependence there and it is explicit.
> >
> > 2. Alright, so David was talking about something else - and that is
> > purely technical. The /social/* code depends on some of the same
> > infrastructure that the gadgets code does. It's not anything special,
> > it used to be the CrossServletState (now guice) and the GadgetToken
> > stuff. OpenSocial relies on GadgetTokens to do security things.
> > social/* doesn't need anything oauth at the moment, but it will when
> > the server-to-server apis get in there.
> >
> > 3. Given #2 I wanted to get some code in there quickly. The easy way
> > was to put it on the same server to get all of the same benefits.
> > That's the only reason I did it. And we can change it to whatever fits
> > out needs too. However, I would like to see us have a couple of things
> > satisfied.
> >
> > a) in dev - it would be nice to run just one command that runs
> > everything and allows the samplecontainer to work. (the
> > samplecontainer relies on both the gadgets server and the socialdata
> > stuff)
> >
> > b) in prod - it would be nice if it were easy to run 2 deployments or
> > 1 deployment
> >
> > c) the server that hosts the socialdata servlet should also host the
> > javascript. Otherwise, you've got two halves of the wire format on two
> > different servers - and that just seems like a recipe for disaster.
> > (the samplecontainer should maybe also live in the social server but
> > it uses everything.. so i'm not really sure how we will want that to
> > work)
> >
> > I don't know how to do this. So, if someone can send in a patch that
> > fixes all the maven stuff up to make that happen then let's go for it.
> > In addition, we would probably need to do a directory shuffle like
> > what Kevin described where we explicitly mark things as common or
> > whatever.
> >
> >
> > 4. Lastly - the RESTful server should be the same server as the
> > socialdata server. They read from the same backends, and produce the
> > same kind of thing (a wire format that somebody can depend on - like
> > javascript). So, I don't think we need to make 3 servers. Hopefully
> > the socialdata code and the RESTful code will be one and the same and
> > the wire formats will be one and the same. That's what we should
> > strive for just from a "duplicate code is evil" perspective. People
> > have already filed bugs against us to do just that, and we will get
> > there - but the RESTful spec needs to be done, and the code needs to
> > be implemented. Until then, we will keep working on the current stuff
> > to make it usable. Hopefully, most of the code we have in social/* can
> > be reused in some manner. But anyway, that's more long term as nobody
> > has started implementing anything in that area yet.
>
>
> I think that ultimately there are 2 servers and 3 projects (aside from the
> container page itself, of course):
>
> - Server A / Project A The gadget renderer, which *includes* connections for
> the opensocial javascript APIs, even if they're little more than delegation
> to an RPC channel.
>
> - Server B / Project B The data server, which should probably include the
> RESTful wire format.
>
> - Project C: Common stuff. OAuth stuff belongs here as well. This isn't a
> standalone server, it's common code used by both the gadget rendering server
> and the social API server. Recycling the JSON RESTful binding for use in
> both the gadget server and the API server would be awesome, but it isn't a
> strict requirement.
>
> Everything except the most trivial deployments is going to want that
> separation. If you want 1 command to kick off both servers, that's what we
> have shell scripts for (maven can probably do this anyway though).
>
> One monolithic server will be a nightmare to maintain, and it makes little
> sense in a real world production scenario.
>
> --
> ~Kevin
>
Re: Social data request URL issue
Posted by Kevin Brown <et...@google.com>.
On Thu, Apr 3, 2008 at 5:57 AM, Chris Chabot <ch...@xs4all.nl> wrote:
> Ok so i can clean up the PHP code, once someone contributes maven magic
> to java land, oh how i love inter-dependencies sometimes, I'll wait with
> my cleanup then 'till we find a mvn wizzard :)
Why would you need maven changes to modify your PHP code? You're not using
maven to "build" (whatever that would mean...) the PHP code, right?
>
> -- Chris
>
> On Thu, 2008-04-03 at 13:20 +0200, Cassie wrote:
>
> >
> >
> > yup - as long as someone can setup all the maven magic correctly and
> > make a shell script to run both at once :)
> >
> >
>
--
~Kevin
Re: Social data request URL issue
Posted by Ian Boston <ia...@googlemail.com>.
What mvn magic would you like ?
I converted sakai, which is about 800 pom files from maven 1 to maven
2, certainly not a wizard (if you meant human), but happy to help.
Ian
On 03/04/2008, Chris Chabot <ch...@xs4all.nl> wrote:
> Ok so i can clean up the PHP code, once someone contributes maven magic
> to java land, oh how i love inter-dependencies sometimes, I'll wait with
> my cleanup then 'till we find a mvn wizzard :)
>
>
> -- Chris
>
>
> On Thu, 2008-04-03 at 13:20 +0200, Cassie wrote:
>
> >
> >
> > yup - as long as someone can setup all the maven magic correctly and
> > make a shell script to run both at once :)
> >
> >
>
Re: Social data request URL issue
Posted by Chris Chabot <ch...@xs4all.nl>.
Ok so i can clean up the PHP code, once someone contributes maven magic
to java land, oh how i love inter-dependencies sometimes, I'll wait with
my cleanup then 'till we find a mvn wizzard :)
-- Chris
On Thu, 2008-04-03 at 13:20 +0200, Cassie wrote:
>
>
> yup - as long as someone can setup all the maven magic correctly and
> make a shell script to run both at once :)
>
>
Re: Social data request URL issue
Posted by Cassie <do...@google.com>.
On Thu, Apr 3, 2008 at 1:10 PM, Chris Chabot <ch...@xs4all.nl> wrote:
> Ah ok that must have been my confusion too then.
>
> In the current structure (mirroring the java's structure) i'm
> implimenting a /gadgets/socialdata interface where it now retrieves the
> social information ... Which is where that part of my reasoning and
> assumptions was/were based on.
>
> I'm under the impression we don't actually have a REST interface as of
> yet, so i presumed this will stick around for a little bit longer..
> Hence my desire to put the current /gadgets/socialdata under /social for
> now, until we have a proper REST solution in place.
>
> The main reason, is pretty much how i started all of this, it's a mess
> in a lot of ways to mix these 2 things in the PHP code .. and the main
> reason you were not able to put them under 2 seperate url's (/gadgets
> and /social) was due to the requirement to have it all be one server /
> project.... Which i believe now has been agreed on shouldn't be a
> requirement anymore? (due to the rest and gadget stuff being split
> anyhow)
yup - as long as someone can setup all the maven magic correctly and
make a shell script to run both at once :)
>
> -- Chris
>
>
>
> On Thu, 2008-04-03 at 12:52 +0200, Cassie wrote:
>
> > I'm sorry Chris but I didn't quite catch the difference between what
> > goes under /social and what goes under /rest..
> >
> > Long term there would only be one server/code directory for serving
> > social data. This would be the restful api server. Then, the
> > javascript part of opensocial would talk restful wire format to that
> > server. So, why do we need two directories when its all going to be
> > the same thing? (I'm probably just missing something)
> >
> > Thanks.
> >
> > - Cassie
>
Re: Social data request URL issue
Posted by Chris Chabot <ch...@xs4all.nl>.
Ah ok that must have been my confusion too then.
In the current structure (mirroring the java's structure) i'm
implimenting a /gadgets/socialdata interface where it now retrieves the
social information ... Which is where that part of my reasoning and
assumptions was/were based on.
I'm under the impression we don't actually have a REST interface as of
yet, so i presumed this will stick around for a little bit longer..
Hence my desire to put the current /gadgets/socialdata under /social for
now, until we have a proper REST solution in place.
The main reason, is pretty much how i started all of this, it's a mess
in a lot of ways to mix these 2 things in the PHP code .. and the main
reason you were not able to put them under 2 seperate url's (/gadgets
and /social) was due to the requirement to have it all be one server /
project.... Which i believe now has been agreed on shouldn't be a
requirement anymore? (due to the rest and gadget stuff being split
anyhow)
-- Chris
On Thu, 2008-04-03 at 12:52 +0200, Cassie wrote:
> I'm sorry Chris but I didn't quite catch the difference between what
> goes under /social and what goes under /rest..
>
> Long term there would only be one server/code directory for serving
> social data. This would be the restful api server. Then, the
> javascript part of opensocial would talk restful wire format to that
> server. So, why do we need two directories when its all going to be
> the same thing? (I'm probably just missing something)
>
> Thanks.
>
> - Cassie
Re: Social data request URL issue
Posted by Cassie <do...@google.com>.
I'm sorry Chris but I didn't quite catch the difference between what
goes under /social and what goes under /rest..
Long term there would only be one server/code directory for serving
social data. This would be the restful api server. Then, the
javascript part of opensocial would talk restful wire format to that
server. So, why do we need two directories when its all going to be
the same thing? (I'm probably just missing something)
Thanks.
- Cassie
On Thu, Apr 3, 2008 at 12:44 PM, Chris Chabot <ch...@xs4all.nl> wrote:
> I'm glad to see this thread surface again, it didn't leave me with a
> satisfied feeling last time to have to hack the 'social' part into the
> 'gadget' tree, my thinking on it has been mirrored by a lot of posts
> here already so i won't go and repeat my self or others.
>
> But to bring this back into practicality for the PHP part of shindig,
> from this response i see that your still proposing 2 URL entry points
> right? aka:
> /gadgets/(.*)
> /rest/(.*)
>
> Which, while it'll be great that the logical source will be split out,
> doesn't help me on the PHP side of things of having to mix logically
> different functions:
> 1) Rendering a XML file into a HTML gadget, and
> 2) Serving social data to a gadget
>
> Where 1 and 2 could be completely different products even using
> different languages, as long as the wire format is compatible (and the
> goal is that this would instance be the case for the the java and php
> shindig versions). This gives some flexibility to, again as example,
> integrate the social data service directly on your data source (using
> the PHP version) while using the Java version to render gadgets..
>
> While it is indeed possible to make a gadget+social interface server,
> and hope that everyone will want to make a RPC (xml rpc, soap, json,
> etc) service following the API of the social interface ... in practise
> this probably isn't true, and even on this list the dev's frequently use
> the example of "Implement some kind of social data source into the
> gadget/social server.." so sometimes implying that putting the data hook
> directly into the shindig code structure and not through an external RPC
> mechanism is a good thing :)
>
> It would really help me so much on the PHP side of things, and would
> feel just a lot more like the proper approach if we could have 3
> different entry points (aka 3 servers in java slang?):
> /gadgets/(.*)
> /social/(.*)
> /rest/(.*)
>
> This would (at least in my case) mean i would have 4 code directories:
> /php/gadgets
> /php/social
> /php/rest
> /php/common
>
> This would make my code a whole lot cleaner, be more logical for an
> outsider to understand, easier to deploy separately and a lot easier to
> maintain too.. And all the while it doesn't break the original scenario
> where the 'social' part of it just RPC's the data from a different
> location, it however does add the flexibility to make a choice per
> deployment which components and infrastructure works for you.
>
> -- Chris
>
>
>
> On Thu, 2008-04-03 at 02:48 -0700, Kevin Brown wrote:
>
> >
> >
> > I think that ultimately there are 2 servers and 3 projects (aside
> > from the
> > container page itself, of course):
> >
> > - Server A / Project A The gadget renderer, which *includes*
> > connections for
> > the opensocial javascript APIs, even if they're little more than
> > delegation
> > to an RPC channel.
> >
> > - Server B / Project B The data server, which should probably include
> > the
> > RESTful wire format.
> >
> > - Project C: Common stuff. OAuth stuff belongs here as well. This
> > isn't a
> > standalone server, it's common code used by both the gadget rendering
> > server
> > and the social API server. Recycling the JSON RESTful binding for use
> > in
> > both the gadget server and the API server would be awesome, but it
> > isn't a
> > strict requirement.
> >
> > Everything except the most trivial deployments is going to want that
> > separation. If you want 1 command to kick off both servers, that's
> > what we
> > have shell scripts for (maven can probably do this anyway though).
> >
> > One monolithic server will be a nightmare to maintain, and it makes
> > little
> > sense in a real world production scenario.
>
Re: Social data request URL issue
Posted by Chris Chabot <ch...@xs4all.nl>.
I'm glad to see this thread surface again, it didn't leave me with a
satisfied feeling last time to have to hack the 'social' part into the
'gadget' tree, my thinking on it has been mirrored by a lot of posts
here already so i won't go and repeat my self or others.
But to bring this back into practicality for the PHP part of shindig,
from this response i see that your still proposing 2 URL entry points
right? aka:
/gadgets/(.*)
/rest/(.*)
Which, while it'll be great that the logical source will be split out,
doesn't help me on the PHP side of things of having to mix logically
different functions:
1) Rendering a XML file into a HTML gadget, and
2) Serving social data to a gadget
Where 1 and 2 could be completely different products even using
different languages, as long as the wire format is compatible (and the
goal is that this would instance be the case for the the java and php
shindig versions). This gives some flexibility to, again as example,
integrate the social data service directly on your data source (using
the PHP version) while using the Java version to render gadgets..
While it is indeed possible to make a gadget+social interface server,
and hope that everyone will want to make a RPC (xml rpc, soap, json,
etc) service following the API of the social interface ... in practise
this probably isn't true, and even on this list the dev's frequently use
the example of "Implement some kind of social data source into the
gadget/social server.." so sometimes implying that putting the data hook
directly into the shindig code structure and not through an external RPC
mechanism is a good thing :)
It would really help me so much on the PHP side of things, and would
feel just a lot more like the proper approach if we could have 3
different entry points (aka 3 servers in java slang?):
/gadgets/(.*)
/social/(.*)
/rest/(.*)
This would (at least in my case) mean i would have 4 code directories:
/php/gadgets
/php/social
/php/rest
/php/common
This would make my code a whole lot cleaner, be more logical for an
outsider to understand, easier to deploy separately and a lot easier to
maintain too.. And all the while it doesn't break the original scenario
where the 'social' part of it just RPC's the data from a different
location, it however does add the flexibility to make a choice per
deployment which components and infrastructure works for you.
-- Chris
On Thu, 2008-04-03 at 02:48 -0700, Kevin Brown wrote:
>
>
> I think that ultimately there are 2 servers and 3 projects (aside
> from the
> container page itself, of course):
>
> - Server A / Project A The gadget renderer, which *includes*
> connections for
> the opensocial javascript APIs, even if they're little more than
> delegation
> to an RPC channel.
>
> - Server B / Project B The data server, which should probably include
> the
> RESTful wire format.
>
> - Project C: Common stuff. OAuth stuff belongs here as well. This
> isn't a
> standalone server, it's common code used by both the gadget rendering
> server
> and the social API server. Recycling the JSON RESTful binding for use
> in
> both the gadget server and the API server would be awesome, but it
> isn't a
> strict requirement.
>
> Everything except the most trivial deployments is going to want that
> separation. If you want 1 command to kick off both servers, that's
> what we
> have shell scripts for (maven can probably do this anyway though).
>
> One monolithic server will be a nightmare to maintain, and it makes
> little
> sense in a real world production scenario.
Re: Social data request URL issue
Posted by Kevin Brown <et...@google.com>.
On Thu, Apr 3, 2008 at 2:27 AM, Cassie <do...@apache.org> wrote:
> My my - quite a thread happened while I was sleeping. There were like
> 20 million things that came up, so let me try to address some of them.
>
> 1. For complying to the opensocial spec you -must- be able to render
> and correctly display gadgets. Opensocial the spec relies on the
> gadget spec. There is dependence there and it is explicit.
>
> 2. Alright, so David was talking about something else - and that is
> purely technical. The /social/* code depends on some of the same
> infrastructure that the gadgets code does. It's not anything special,
> it used to be the CrossServletState (now guice) and the GadgetToken
> stuff. OpenSocial relies on GadgetTokens to do security things.
> social/* doesn't need anything oauth at the moment, but it will when
> the server-to-server apis get in there.
>
> 3. Given #2 I wanted to get some code in there quickly. The easy way
> was to put it on the same server to get all of the same benefits.
> That's the only reason I did it. And we can change it to whatever fits
> out needs too. However, I would like to see us have a couple of things
> satisfied.
>
> a) in dev - it would be nice to run just one command that runs
> everything and allows the samplecontainer to work. (the
> samplecontainer relies on both the gadgets server and the socialdata
> stuff)
>
> b) in prod - it would be nice if it were easy to run 2 deployments or
> 1 deployment
>
> c) the server that hosts the socialdata servlet should also host the
> javascript. Otherwise, you've got two halves of the wire format on two
> different servers - and that just seems like a recipe for disaster.
> (the samplecontainer should maybe also live in the social server but
> it uses everything.. so i'm not really sure how we will want that to
> work)
>
> I don't know how to do this. So, if someone can send in a patch that
> fixes all the maven stuff up to make that happen then let's go for it.
> In addition, we would probably need to do a directory shuffle like
> what Kevin described where we explicitly mark things as common or
> whatever.
>
>
> 4. Lastly - the RESTful server should be the same server as the
> socialdata server. They read from the same backends, and produce the
> same kind of thing (a wire format that somebody can depend on - like
> javascript). So, I don't think we need to make 3 servers. Hopefully
> the socialdata code and the RESTful code will be one and the same and
> the wire formats will be one and the same. That's what we should
> strive for just from a "duplicate code is evil" perspective. People
> have already filed bugs against us to do just that, and we will get
> there - but the RESTful spec needs to be done, and the code needs to
> be implemented. Until then, we will keep working on the current stuff
> to make it usable. Hopefully, most of the code we have in social/* can
> be reused in some manner. But anyway, that's more long term as nobody
> has started implementing anything in that area yet.
I think that ultimately there are 2 servers and 3 projects (aside from the
container page itself, of course):
- Server A / Project A The gadget renderer, which *includes* connections for
the opensocial javascript APIs, even if they're little more than delegation
to an RPC channel.
- Server B / Project B The data server, which should probably include the
RESTful wire format.
- Project C: Common stuff. OAuth stuff belongs here as well. This isn't a
standalone server, it's common code used by both the gadget rendering server
and the social API server. Recycling the JSON RESTful binding for use in
both the gadget server and the API server would be awesome, but it isn't a
strict requirement.
Everything except the most trivial deployments is going to want that
separation. If you want 1 command to kick off both servers, that's what we
have shell scripts for (maven can probably do this anyway though).
One monolithic server will be a nightmare to maintain, and it makes little
sense in a real world production scenario.
--
~Kevin
Re: Social data request URL issue
Posted by Cassie <do...@apache.org>.
My my - quite a thread happened while I was sleeping. There were like
20 million things that came up, so let me try to address some of them.
1. For complying to the opensocial spec you -must- be able to render
and correctly display gadgets. Opensocial the spec relies on the
gadget spec. There is dependence there and it is explicit.
2. Alright, so David was talking about something else - and that is
purely technical. The /social/* code depends on some of the same
infrastructure that the gadgets code does. It's not anything special,
it used to be the CrossServletState (now guice) and the GadgetToken
stuff. OpenSocial relies on GadgetTokens to do security things.
social/* doesn't need anything oauth at the moment, but it will when
the server-to-server apis get in there.
3. Given #2 I wanted to get some code in there quickly. The easy way
was to put it on the same server to get all of the same benefits.
That's the only reason I did it. And we can change it to whatever fits
out needs too. However, I would like to see us have a couple of things
satisfied.
a) in dev - it would be nice to run just one command that runs
everything and allows the samplecontainer to work. (the
samplecontainer relies on both the gadgets server and the socialdata
stuff)
b) in prod - it would be nice if it were easy to run 2 deployments or
1 deployment
c) the server that hosts the socialdata servlet should also host the
javascript. Otherwise, you've got two halves of the wire format on two
different servers - and that just seems like a recipe for disaster.
(the samplecontainer should maybe also live in the social server but
it uses everything.. so i'm not really sure how we will want that to
work)
I don't know how to do this. So, if someone can send in a patch that
fixes all the maven stuff up to make that happen then let's go for it.
In addition, we would probably need to do a directory shuffle like
what Kevin described where we explicitly mark things as common or
whatever.
4. Lastly - the RESTful server should be the same server as the
socialdata server. They read from the same backends, and produce the
same kind of thing (a wire format that somebody can depend on - like
javascript). So, I don't think we need to make 3 servers. Hopefully
the socialdata code and the RESTful code will be one and the same and
the wire formats will be one and the same. That's what we should
strive for just from a "duplicate code is evil" perspective. People
have already filed bugs against us to do just that, and we will get
there - but the RESTful spec needs to be done, and the code needs to
be implemented. Until then, we will keep working on the current stuff
to make it usable. Hopefully, most of the code we have in social/* can
be reused in some manner. But anyway, that's more long term as nobody
has started implementing anything in that area yet.
Alright, I hope I didn't add more flame to the fire. Hopefully it
makes some sense.
- Cassie
On Thu, Apr 3, 2008 at 8:37 AM, Kevin Brown <et...@google.com> wrote:
>
> On Wed, Apr 2, 2008 at 11:11 PM, Brian Eaton <be...@google.com> wrote:
>
> > On Wed, Apr 2, 2008 at 10:41 PM, Kevin Brown <et...@google.com> wrote:
> > > The shared pieces are the data accessors (both the JS and REST APIs need
> > > these). Ideally I'd like to see the wire format used by the JS APIs to
> > > communicate with the back end being identical as that of the JSON
> > bindings
> > > for the RESTful state, although that's not a strict requirement.
> >
> > My guess is stuff in the util/* directory will end up being useful as
> > well.
> >
>
> Agreed.
>
> Is anyone familiar enough with maven that they might show me how (or even
> provide a patch!) that would let us have 3 separate projects? Something
> like:
>
> trunk/java/gadgets <-- everything under the org.apache.shindig.gadgets
> package
> trunk/java/rest <-- non-shared parts of the RESTful API
> trunk/java/common <-- everything shared
>
> I'd expect some parts of org.apache.shindig.gadgets to move into "common"
> (OAuth bits mostly, I think), and everything currently in the
> org.apache.shindig.util package as well. We could drop the util stuff into a
> completely separate package as well.
>
> There is already a top level pom.xml, so I assume that we can just create
> pom.xml files for the other two directories and then set up dependencies
> appropriately. I have no idea how to make that happen though -- this is the
> first maven project I've ever worked on.
>
> --
> ~Kevin
>
Re: Social data request URL issue
Posted by Kevin Brown <et...@google.com>.
On Wed, Apr 2, 2008 at 11:11 PM, Brian Eaton <be...@google.com> wrote:
> On Wed, Apr 2, 2008 at 10:41 PM, Kevin Brown <et...@google.com> wrote:
> > The shared pieces are the data accessors (both the JS and REST APIs need
> > these). Ideally I'd like to see the wire format used by the JS APIs to
> > communicate with the back end being identical as that of the JSON
> bindings
> > for the RESTful state, although that's not a strict requirement.
>
> My guess is stuff in the util/* directory will end up being useful as
> well.
>
Agreed.
Is anyone familiar enough with maven that they might show me how (or even
provide a patch!) that would let us have 3 separate projects? Something
like:
trunk/java/gadgets <-- everything under the org.apache.shindig.gadgets
package
trunk/java/rest <-- non-shared parts of the RESTful API
trunk/java/common <-- everything shared
I'd expect some parts of org.apache.shindig.gadgets to move into "common"
(OAuth bits mostly, I think), and everything currently in the
org.apache.shindig.util package as well. We could drop the util stuff into a
completely separate package as well.
There is already a top level pom.xml, so I assume that we can just create
pom.xml files for the other two directories and then set up dependencies
appropriately. I have no idea how to make that happen though -- this is the
first maven project I've ever worked on.
--
~Kevin
Re: Social data request URL issue
Posted by Brian Eaton <be...@google.com>.
On Wed, Apr 2, 2008 at 10:41 PM, Kevin Brown <et...@google.com> wrote:
> The shared pieces are the data accessors (both the JS and REST APIs need
> these). Ideally I'd like to see the wire format used by the JS APIs to
> communicate with the back end being identical as that of the JSON bindings
> for the RESTful state, although that's not a strict requirement.
My guess is stuff in the util/* directory will end up being useful as well.
Re: Social data request URL issue
Posted by Kevin Brown <et...@google.com>.
On Wed, Apr 2, 2008 at 9:23 PM, Nick Lothian <nl...@educationau.edu.au>
wrote:
> What infrastructure can be shared?
The shared pieces are the data accessors (both the JS and REST APIs need
these). Ideally I'd like to see the wire format used by the JS APIs to
communicate with the back end being identical as that of the JSON bindings
for the RESTful state, although that's not a strict requirement.
>
> I can see that code in the org.apache.shindig.social.opensocial.model
> package is likely to be useful in both systems, but that can be handled by
> breaking the build up.
>
> Nick
>
>
>
> -----Original Message-----
> From: Brian Eaton [mailto:beaton@google.com]
> Sent: Thursday, 3 April 2008 2:30 PM
> To: shindig-dev@incubator.apache.org
> Subject: Re: Social data request URL issue
>
> On Wed, Apr 2, 2008 at 8:07 PM, John Panzer <jp...@google.com> wrote:
> <snip>
> > All of these benefit from separating the code and URLs of the two
> > subsystems.
> <snip>
>
> Can we please not separate the code too much? There's a certain
> amount of infrastructure that can be usefully shared between the two
> services.
>
> IMPORTANT: This e-mail, including any attachments, may contain private or
> confidential information. If you think you may not be the intended
> recipient, or if you have received this e-mail in error, please contact the
> sender immediately and delete all copies of this e-mail. If you are not the
> intended recipient, you must not reproduce any part of this e-mail or
> disclose its contents to any other party. This email represents the views of
> the individual sender, which do not necessarily reflect those of
> education.au limited except where the sender expressly states otherwise. It
> is your responsibility to scan this email and any files transmitted with it
> for viruses or any other defects. education.au limited will not be liable
> for any loss, damage or consequence caused directly or indirectly by this
> email.
>
--
~Kevin
RE: Social data request URL issue
Posted by Nick Lothian <nl...@educationau.edu.au>.
What infrastructure can be shared?
I can see that code in the org.apache.shindig.social.opensocial.model package is likely to be useful in both systems, but that can be handled by breaking the build up.
Nick
-----Original Message-----
From: Brian Eaton [mailto:beaton@google.com]
Sent: Thursday, 3 April 2008 2:30 PM
To: shindig-dev@incubator.apache.org
Subject: Re: Social data request URL issue
On Wed, Apr 2, 2008 at 8:07 PM, John Panzer <jp...@google.com> wrote:
<snip>
> All of these benefit from separating the code and URLs of the two
> subsystems.
<snip>
Can we please not separate the code too much? There's a certain
amount of infrastructure that can be usefully shared between the two
services.
IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of education.au limited except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.
Re: Social data request URL issue
Posted by David Primmer <da...@gmail.com>.
On Wed, Apr 2, 2008 at 9:00 PM, Brian Eaton <be...@google.com> wrote:
> On Wed, Apr 2, 2008 at 8:07 PM, John Panzer <jp...@google.com> wrote:
> <snip>
>
> > All of these benefit from separating the code and URLs of the two
> > subsystems.
> <snip>
>
> Can we please not separate the code too much? There's a certain
> amount of infrastructure that can be usefully shared between the two
> services.
Can you help identify this infrastructure? I'm guessing some of it has
to do with the OAuth stuff you've been involved in.
davep
Re: Social data request URL issue
Posted by Brian Eaton <be...@google.com>.
On Wed, Apr 2, 2008 at 8:07 PM, John Panzer <jp...@google.com> wrote:
<snip>
> All of these benefit from separating the code and URLs of the two
> subsystems.
<snip>
Can we please not separate the code too much? There's a certain
amount of infrastructure that can be usefully shared between the two
services.
Re: Social data request URL issue
Posted by John Panzer <jp...@google.com>.
On Wed, Apr 2, 2008 at 6:35 PM, Kevin Brown <et...@google.com> wrote:
> On Wed, Apr 2, 2008 at 6:08 PM, David Primmer <da...@gmail.com>
> wrote:
>
> > 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 <do...@apache.org> 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.
>
>
> Yes you do. You can't support opensocial without supporting the gadgets
> spec
> as well. They're effectively a single spec, although there's currently a
> pedantic separation due to the way that the specs have evolved.
>
Consider three scenarios:
1. PHP API server, Java gadgets server (where the API is tightly bound to an
existing PHP site). Seems like a reasonable thing to want to do, yet the
PHP API server isn't serving gadgets.
2. Gadget servers running in a geo-distributed manner to minimize gadget
rendering latency, while the API server is running in one or two datacenters
to minimize distance-to-data. Seems like a possibly reasonable approach.
3. Gadget server functionality is outsourced to someone else (the syndicated
gmodules.com scenario), while the API server is run by the organization that
owns the social data. Some issues with how to communicate via JS but
certainly do-able in a federated model.
All of these benefit from separating the code and URLs of the two
subsystems.
More to the general point, it seems very odd to have a truly generic data
API be modelled as a feature of the gadget server. Assuming that social
gadgets use the generic API, the dependency would be the other way (gadgets
depend on the API, the API does not depend on gadgets. An OpenSocial
container has to provide both of course, but there are many reasons to
deploy them separately.
Re: Social data request URL issue
Posted by Kevin Brown <et...@google.com>.
On Wed, Apr 2, 2008 at 8:20 PM, David Primmer <da...@gmail.com>
wrote:
> In Wed, Apr 2, 2008 at 6:35 PM, Kevin Brown <et...@google.com> wrote:
> > On Wed, Apr 2, 2008 at 6:08 PM, David Primmer <da...@gmail.com>
> > wrote:
> > > 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.
> >
> >
> > Yes you do. You can't support opensocial without supporting the gadgets
> spec
> > as well. They're effectively a single spec, although there's currently
> a
> > pedantic separation due to the way that the specs have evolved.
> >
>
> You're right about supporting opensocial. What I meant by "participate
> in opensocial' was similar to what John outlined below, where the
> person implementing the server could only be doing the data api part
> of the "support" of opensocial and some other server or even other
> company could provide the other aspects. Didn't mean to confuse
> matters.
Of course -- the gadget rendering components can (and should be) logically
separated from the API server. A monolithic production setup would be
difficult to maintain, and I shudder to think about the pain we'd have to go
through for actually implementing it in Shindig! :)
What exists in the "social" package right now is the wiring for making the
opensocial javascript libraries work. More likely than not, there will be
significant overlap between this code and the API server code. Figuring out
the logical separation there is important to allow the social API server to
develop independently of the gadget rendering server.
Re: Social data request URL issue
Posted by David Primmer <da...@gmail.com>.
In Wed, Apr 2, 2008 at 6:35 PM, Kevin Brown <et...@google.com> wrote:
> On Wed, Apr 2, 2008 at 6:08 PM, David Primmer <da...@gmail.com>
> wrote:
> > 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.
>
>
> Yes you do. You can't support opensocial without supporting the gadgets spec
> as well. They're effectively a single spec, although there's currently a
> pedantic separation due to the way that the specs have evolved.
>
You're right about supporting opensocial. What I meant by "participate
in opensocial' was similar to what John outlined below, where the
person implementing the server could only be doing the data api part
of the "support" of opensocial and some other server or even other
company could provide the other aspects. Didn't mean to confuse
matters.
davep
Re: Social data request URL issue
Posted by Kevin Brown <et...@google.com>.
On Wed, Apr 2, 2008 at 6:08 PM, David Primmer <da...@gmail.com>
wrote:
> 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 <do...@apache.org> 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.
Yes you do. You can't support opensocial without supporting the gadgets spec
as well. They're effectively a single spec, although there's currently a
pedantic separation due to the way that the specs have evolved.
>
> > - 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 <ch...@xs4all.nl>
> 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
> > >
> >
>
--
~Kevin
Re: Social data request URL issue
Posted by David Primmer <da...@gmail.com>.
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 <do...@apache.org> 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 <ch...@xs4all.nl> 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
> >
>
Re: Social data request URL issue
Posted by Cassie <do...@apache.org>.
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.
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.
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
- 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.
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"?
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 <ch...@xs4all.nl> 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
>