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