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? -- 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] > For more options, visit this group at > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en > -~----------~----~----~----~------~----~------~--~--- > >
