Adam is correct Scott.
My statement should not be paraphrased as "why do we need osml?". I
definitely -agree- that we should have osml.
However, if osml needs to get data I think it should use the existing
format. You can put it in a shiny xml wrapper if you want:
<os:DataRequest request="{method : person.get, userId : @owner, id :
get_owner}" />
or put it in the preload as Adam mentioned.
Anyway, I don't want to derail Adam's train of thought.
Are there any other requirements?
- Cassie
On Fri, Sep 19, 2008 at 8:57 AM, 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?
>
> -- 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
> -~----------~----~----~----~------~----~------~--~---
>
>
