I'm +1 on that, but isn't the URI template parsing supposed to be part of
the whole XRDS dance? :)
On Fri, Nov 21, 2008 at 1:08 AM, Joseph Smarr <[EMAIL PROTECTED]> wrote:
> By the way, is anyone actually using URI templates and doing a non-standard
> path for /@me/@self in the wild? We missed that bit of flexibility in our
> alignment with Portable Contacts (which only supports /@me/@self style URLs)
> and IMO it's going to cause a lot of extra and unnecessary pain for
> consumers, who will now have to use a URI template parser and try to
> construct the right URL, rather than just using a standard scheme. If no one
> is currently using it, I would vote to remove that flexibility from the
> OpenSocial spec to fix the alignment and simplify things. Anyone disagree?
>
> Thanks, js
>
>
> On Thu, Nov 20, 2008 at 1:09 PM, Chris Chabot <[EMAIL PROTECTED]> wrote:
>
>> 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]
>> > >>
>> > >>
>> > >>
>> > >>
>> > >
>> >
>> >
>> >
>> >
>>
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> [EMAIL PROTECTED]
> To unsubscribe from this group, send email to
> [EMAIL PROTECTED]<[EMAIL PROTECTED]>
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
