Chris, Thanks for the note. This has definitely helped me understand this a bit more. Perhaps I was coming at it from the wrong angle. I was looking at this from the perspective that OpenSocial can be thought of as a collection of services, e.g. People, Activity, Group, et. The "container" was the place where all these services lived. I think this is similar to your statement below "shindig is 'just the opensocial service server'". I was not thinking that website == container, but rather that the container simply provides these services to any consuming application, e.g. a website. Because of this, it seemed to make sense that you could ask (eg discover) what services the container offered.
I was coming at it this way because one of the use cases I'm looking at is augmenting existing applications with social networking capability. The existing application may not be responsible for managing the social network information, but simply working with it. My original thinking was that I could "plug-in"/"link-to" any OpenSocial container and use discovery to determine what services were available--independent of if "the container" had a website. In the scenario where website == container, then my newly enabled application would be considered the "container" and thus responsible for producing the XRDS information. So is the scenario I've outlined, where the container offers a set of social networking services that are simply consumed by other applications, web sites, et. make sense, or am I off in the weeds getting bit by mosquitoes? Thanks, -Mark W. _______________________________________________________________________________________________________________ Mark Weitzel | STSM | IBM Software Group | (919) 543 0625 | weitzelm at us.ibm.com From: Chris Chabot <[EMAIL PROTECTED]> To: [email protected] Date: 11/19/2008 12:35 PM Subject: Re: container discovery support ps, the whole point of XRDS-simple is to *discover* those hidden, long, site specific URLs for the documented services (openid, portablecontacts, oauth, opensocial). Say that you wanted to query some social information from www.myspace.com; The social services live on quite a different url, so by querying the main site URL you get the references to the social end points, and you can proceed to talk REST with them :) the same for openid and all other protocols that use XRDS, the assumption is that those services live under 'random urls' and you need a way to discover them On Wed, Nov 19, 2008 at 6:24 PM, Chris Chabot <[EMAIL PROTECTED]> wrote: > I must've failed to be clear in my previous response, my apologies. > > The XRDS thing is a entirely container related affair ... shindig is 'just > the opensocial service server', and in no way, shape or form anything > 'website' related. (the website == container in opensocial lingo) and the > website is the entity that people will hit for the XRDS document. (ie > www.mysite.com and not obscured > some.shindig.url.at.some.mysite-modules.com). > > As such it's not really shindig's job to respond to the request and it > *shouldn't* be implemented in it, so the error your getting is quite correct > :) > > Instead in whatever site your OpenSocial'izing, check for the XRDS header > there and output your XRDS document there, which then returns to shindig's > REST end points. > > if you don't have any dynamic code driving the main site (or no access to > it), you can also add a meta tag to the home page in the form of: > > <meta http-equiv="X-XRDS-Location" content=" http://www.mysite.com/xrds/url"; /> > > The partuza example was more to demonstrate the 'site' part of it and how > it should look in practise, and not so much a suggestion that that's what > you should be using :) (but do note that partuza works fine with > java-shindig too :) > > > > > On Wed, Nov 19, 2008 at 6:07 PM, Mark D Weitzel <[EMAIL PROTECTED]>wrote: > >> Chris, >> Thanks for the response. Jason had ping'd me the Partuza URL in IRC prior >> to me posting my question so I was able to see something like what I'd >> expect when I make a discovery request to a "vanilla" shindig. For us, >> Partuza is a great first step, but since we would like to build a >> container that is Java based, I'm not sure the php code from partuza will >> fit. That said, I realized, based on your note, that the URL I was >> hitting is wrong. >> Based on your feedback, here's what I tried: >> >> Http Request: >> GET / HTTP/1.1 >> Accept: application/xrds+xml >> User-Agent: Jakarta Commons-HttpClient/3.1 >> Host: localhost:8080 >> >> And the response http header: >> HTTP/1.1 200 OK >> Content-Type: text/html; charset=utf-8 >> Content-Length: 476 >> Server: Jetty(6.1.9) >> >> And the response body: >> <HTML><HEAD><TITLE>Directory: /</TITLE></HEAD><BODY> >> <H1>Directory: /</H1><TABLE BORDER=0><TR><TD><A >> HREF="/META-INF/">META-INF/ </TD><TD ALIGN=right>102 >> bytes </TD><TD>Nov 7, 2008 4:04:56 PM</TD></TR> >> <TR><TD><A HREF="/WEB-INF/">WEB-INF/ </TD><TD ALIGN=right>272 >> bytes </TD><TD>Nov 7, 2008 4:04:56 PM</TD></TR> >> <TR><TD><A HREF="/gadgets/">gadgets/ </TD><TD ALIGN=right>102 >> bytes </TD><TD>Nov 7, 2008 4:04:55 PM</TD></TR> >> </TABLE> >> </BODY></HTML> >> >> Clearly not the document we are looking to get back. Which brings me back >> to my original question. Does shindig provide hooks for this out of the >> box or is this something that I've got to implement on my own? >> >> I was also wondering if discovery is required by the containers. Section >> 5 of the REST spec says that the container MUST support the service types >> below and MAY support other ones. But it does not say if the container >> must support discovery. >> >> Thanks, >> -Mark W. >> >> >> _______________________________________________________________________________________________________________ >> Mark Weitzel | STSM | IBM Software Group | (919) 543 0625 | >> [EMAIL PROTECTED] >> >> >> >> From: >> Chris Chabot <[EMAIL PROTECTED]> >> To: >> [email protected] >> Date: >> 11/19/2008 05:07 AM >> Subject: >> Re: container discovery support >> >> >> >> Normally the URL you would hit for XRDS-simple discovery is the main site >> url, and not the shindig server instance, ie >> http://www.partuza.nl and not >> http://some.instance.thats.not.documented.partuza.nl :-) >> >> If you want to play with XRDS support, check http://www.partuza.nl, it >> supports pretty much all end-points you might want to test against >> (opensocial, oauth and portablecontacts): >> http://www.chabotc.com/xrds-test.php?url=http://www.partuza.nl >> >> ps, to use the 3 legged oauth support, register on partuza.nl, click >> 'edit' >> next to your name and go to the 'oauth' tab to get a oauth consumer key >> and >> secret to use (yes i'm aware these should be per-app and not per person, >> but for the quick and dirty testing this was easier :P) >> >> >> >> On Wed, Nov 19, 2008 at 4:17 AM, Mark D Weitzel <[EMAIL PROTECTED]> >> wrote: >> >> > I am trying to get the discovery information from a shindig container >> > running on localhost. >> > Here's the http header: >> > GET /social/rest/ HTTP/1.1 >> > Accept: application/xrds+xml >> > User-Agent: Jakarta Commons-HttpClient/3.1 >> > Host: localhost:8080 >> > >> > >> > And here's the http response header: >> > HTTP/1.1 501 The service is not implemented >> > Content-Type: text/html; charset=iso-8859-1 >> > Content-Length: 1442 >> > Server: Jetty(6.1.9) >> > >> > And the response body: >> > <html> >> > <head> >> > <meta http-equiv="Content-Type" content="text/html; >> charset=ISO-8859-1"/> >> > <title>Error 501 The service is not implemented</title> >> > </head> >> > <body><h2>HTTP ERROR: 501</h2><pre>The service is not implemented</pre> >> > <p>RequestURI=/social/rest/</p><p><i><small><a href=" >> > http://jetty.mortbay.org/";>Powered by Jetty://</a></small></i></p><br/> >> > >> > >> > So, this may be a silly question, but am I doing something wrong, or is >> > support for discovery not yet implemented in shindig? >> > >> > Thanks in advance for the help! >> > >> > -Mark W. >> > >> > >> >> _______________________________________________________________________________________________________________ >> > Mark Weitzel | STSM | IBM Software Group | (919) 543 0625 | >> > [EMAIL PROTECTED] >> >> >> >> >
