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 > -~----------~----~----~----~------~----~------~--~--- > >
