Well the use-case your describing is still very much the XRDS use case.
You would want to discover the services on 'foo.bar.com', which you would
ping for an XRDS document to discover if the way to get a person is:
foo.bar.com/social/rest/people/1/@self
or
foo.bar.com/rest?service=people&id=1&[EMAIL PROTECTED]
or
some.other.url.foo.bar.com/foo/social/rest/....etc...
where the end points live is not part of the spec, hence the need for
discovery.
However that doesn't mean you can't hook up your apache/tomkat server to
respond to a '/' + Accept: Application/xrds+xml request with a XRDS
document, even if the services live under the same domain name.
Ps that doesn't mean shindig should respond to it, since shindig would
usually not respond to top level requests ('/'), and only hook up to urls
like /gadgets/* and /social/*.
Hope that helps!
-- Chris
On Wed, Nov 19, 2008 at 11:03 PM, Mark D Weitzel <[EMAIL PROTECTED]>wrote:
> 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]
> >>
> >>
> >>
> >>
> >
>
>
>
>
