On Fri, Sep 19, 2008 at 5:57 PM, Adam Winer <[EMAIL PROTECTED]> wrote:
> > On Fri, Sep 19, 2008 at 8:07 AM, Scott Seely <[EMAIL PROTECTED]> wrote: > > Cassie raises an interesting question which must not have been explained > > earlier. To paraphrase, she asks "Why do we need OSML?" > > > > > > > > OSML arises from a desire from some of the OpenSocial organizations to > offer > > vastly improved processing capabilities and a simpler application design > > experience. The current implementation of OSML on the client should be > > viewed as only one of the possibilities. > > > > > > > > OSML was introduced with an eye towards doing a lot of application > > processing prior to delivering the content to the browser. It should be > > possible to get a large number of artifacts (people, activities, appdata, > > etc.) pushed into the content pushed down to the browser, eliminating > round > > trips from the browseràserver to request extra data. When the server is > > delivering an application to the client, the server typically has > > information about the viewer, the owner, and the application already in > main > > memory. Pushing that data to the client when sending out the initial > > response improves responsiveness on the client and the server. OSML The > > improved expressiveness of markup over script and the improved user > > experience thanks to eliminating a class of requests related to the > initial > > gadget load. > > It seems there's already agreement on the advantage of declaratively > pushing content to the browser to eliminate round-trips. What's under > discussion here is not its utility, but the syntax for its > specification. We have two proposals on the table: > - <os:> elements in <Content> > - JSON RPC in <Preload> > > I'd rather start with a list of requirements: > - Cannot require <Content> - (doesn't work for type="proxied") > - Must support specification per-view > - Must be extensible for new data types > > Anything else? - must not require container implementers to support yet another syntax for accessing social data. 5 is more than enough. > > > -- Adam Winer > > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Adam > > Winer > > Sent: Thursday, September 18, 2008 3:14 PM > > To: [EMAIL PROTECTED] > > Cc: [email protected]; [EMAIL PROTECTED] > > Subject: [opensocial-and-gadgets-spec] Re: Declarative Data Definition > > > > > > > > > > > > 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. > > > > > > > >> > > > >> 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? > > > > > > > > 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". > > > > > > > > -- 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 > -~----------~----~----~----~------~----~------~--~--- > >
