There is the proposal to eliminate the variability in the URLs (jut allow a variable prefix). It'd be good to get closure on those proposals so as to not gum up proposals like these...
If that were in place, RESTful syntax would be the most natural way to pull in content; it's just like an img tag: <img src="./face.jpg"/> vs. <Preload href="./people/@owner..." ... /> (The idea being that Preload hrefs start from wherever the container-specific path prefix ends, so a relative URL gets you the resource you want.) On Fri, Sep 19, 2008 at 9:17 AM, Louis Ryan <[EMAIL PROTECTED]> wrote: > I think using REST based preloads in this context is a bit of a non-starter > because of the variety we allow in the URL structure and all that XRDS > allows. We dont want gadget devs to have to create umpteen different gadget > versions. > > If we agree that XRDS is a bad idea and that all URLs are structured the > same way with some container specific offset then we could do something like > this.. > > <Preload type="opensocial:rest" id="owner" href="/people/@owner..."> > <Preload type="opensocial:rest" id="viewer" href="/people/@viewer..."> > > Note that the REST urls dont carry an id parameter with them explicitly as > RPC does so we would need to allow an optional id attribute to allow > retrieval from DataResponse objects. > > A new XML sytax while perhaps a little prettier I dont think will do > anything to improve adoption so I'd rather avoid creating another format. > > So my votes would be > > +1 JSON-RPC > +0 for REST that acts like XRDS doesnt exist OR a new syntax > -100 for REST with XRDS > > > > > > On Thu, Sep 18, 2008 at 3:37 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > >> On Fri, Sep 19, 2008 at 12:14 AM, Adam Winer <[EMAIL PROTECTED]> wrote: >> >> >>> On Thu, Sep 18, 2008 at 2:54 PM, Evan Gilbert <[EMAIL PROTECTED]> wrote: >>> > The group working on OpenSocial templates is working on a proposal for >>> how >>> > to declaratively define the set of data passed into templates. >>> > >>> > In discussions, it looks like OpenSocial may need a declarative syntax >>> in >>> > other places: >>> > >>> > Data preloading >>> > (possibly) to define what data gets sent to the 3rd party server for >>> the >>> > type="proxied" proposal >>> > >>> > Because this impacts other parts of the spec, we'd like to encourage >>> people >>> > interested in this topic to get involved in the design. There will be >>> > opportunity to give input at all phases of the process, and the final >>> > decision is always put up to a vote on the main spec list. However we'd >>> much >>> > prefer to hear your feedback sooner. >>> > >>> > An example of the kind of syntax we're looking at: >>> > >>> > Replacing >>> > req.add(req.newFetchPersonRequest(opensocial.IdSpec.PersonId.OWNER), >>> > "get_owner"); >>> > With <os:PersonRequest key="get_owner" id="OWNER"> >>> > >>> > and links: >>> > >>> > Template discusison group: >>> http://tech.groups.yahoo.com/group/os-templates/ >>> > In progress proposal for pipelining: >>> > >>> http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Data_Pipelining >>> >>> Procedural question: where should we be discussing this? If it >>> impacts the spec as a whole, I think it belongs on the spec group, not >>> the os-templates working group. I'd think in the end, nothing's in >>> the OpenSocial spec if it hasn't been discussed in its final form on >>> the main list. >> >> >> Nothing goes into OpenSocial without being ratified on this list. It says >> so right here: http://docs.google.com/View?docid=dg3q7jr6_17hs5pbzdg >> >> This goes for templates as a whole (the final version will have to be >> voted on just like every other addition to the specification). >> >> Duplicate syntax is bad for everyone, and I for one am completely against >> it. It's bad enough that we already have to support the javascript wrapper >> objects in addition to 4 or 5 variants of the social data APIs, lets please >> not make it more complicated (and even less portable) than it already is. >> >> >>> >>> >>> > >>> > So... please get involved if you have ideas about how data requests >>> should >>> > be defined. >>> >>> Procedure aside: I'm generally a big fan of strongly-defined syntax, >>> e.g.: >>> <os:PersonRequest key="get_owner" id="OWNER"> >>> vs. something like: >>> {method:"person.get", id:"get_owner, id_spec="OWNER"} >>> >>> The former is much easier to syntactically validate, support with tools, >>> etc. >> >> >>> >>> On the other hand: the latter is much more extensible - is there a >>> plan to support third-party data extensions beyond "custom request >>> handlers", which appear specific to client-side processing? >> >> >> We've been bitten too many times with inflexible data structures like >> that. The latter is really the only viable option. >> >> The requests themselves can easily take the form of *any* social data >> call...see more below. >> >>> >>> >>> The other critical question is *where* these go when used outside of >>> OpenSocial templates: <Features>, or <Content>? I'd mostly like to >>> leave that question to the experts on gadget parsing and rendering, >>> but I think it's been pointed out already that <Content> doesn't exist >>> for type="proxied". >> >> >> We already have HTTP preloads, and social data easily maps to HTTP >> requests (because of the data APIs). We could probably augment the existing >> Preload element for this. >> >> For instance, a REST request might look like this: >> >> <Preload href="<restful path only, not host/port/protocol>" type="rest"/> >> >> Bodies can just be included in the CDATA: >> >> <Preload type="rpc"><![CDATA[{method:"person.get", id:"get_owner, >> id_spec="OWNER"}]]></Preload> >> >> Instead of having to define entirely new, arbitrary constructs (again), we >> can reuse what we already have. >> >> - For templates, the data is available and populated as properties to be >> used in the expressions. >> >> - For gadget preloading (non-proxied), the data can be passed down to the >> client in a transparent way and mapped to the original request so that it >> works seamlessly with existing opensocial calls. This is the same way that >> HTTP preloading is done. >> >> - For gadget preloading (proxied), the data can be pushed across as POST >> to the remote site. >> >> Putting this into the Content section REQUIRES that it is duplicated >> elsewhere to support everything else, because supporting proxied content >> requires it. >> >> >>> >>> >>> -- Adam >>> >>> >>> >> >> > > --~--~---------~--~----~------------~-------~--~----~ > 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 > -~----------~----~----~----~------~----~------~--~--- > >
