On Fri, Sep 19, 2008 at 6:44 PM, Adam Winer <[EMAIL PROTECTED]> wrote:
>
> On Fri, Sep 19, 2008 at 9:22 AM, David Byttow <[EMAIL PROTECTED]>
> wrote:
> > The requirements for preloading data are probably a bit disjoint from the
> > requirements for OS Templates, but as far as OSML interoperability goes:
> >
> > - Must be available to be processed on the client.
>
> What is the subject that goes with this sentence? The preloaded data,
> or the specification for that data request? I'm guessing the latter,
> based on the parameterization example below.
>
> > - Must be able to associate a string key with any given data request.
>
> +1, needed for all use cases.
>
> > - Must be able to parametrize a data request (i.e., <os:PeopleRequest ...
> > page="${page}">)
>
> Preload/proxied probably wouldn't support parameterization, but that's
> a reasonable requirement for the syntax we choose.
I don't understand what "parameterize a data request" means here. If we're
talking about parameters going to the social data server, that's a solid
argument for using the established server to server protocols, which can
already have arbitrary data passed to them.
>
>
> > As I mentioned before, I think it is perfectly reasonable to move forward
> > with a <Preload> or some other type of data-prefetching system that may
> very
> > well partially underpin the data-pipelining system for OSML. There is no
> > requirement that says the systems must be one-in-the-same.
>
> No, but they should be as similar as possible and reasonable.
>
> -- Adam
>
>
> >
> > David
> >
> > On Fri, Sep 19, 2008 at 9:17 AM, Louis Ryan <[EMAIL PROTECTED]> wrote:
> >>
> >> I think using REST based preloads in this context is a bit of a
> >> non-starter because of the variety we allow in the URL structure and all
> >> that XRDS allows. We dont want gadget devs to have to create umpteen
> >> different gadget versions.
> >>
> >> If we agree that XRDS is a bad idea and that all URLs are structured the
> >> same way with some container specific offset then we could do something
> like
> >> this..
> >>
> >> <Preload type="opensocial:rest" id="owner" href="/people/@owner...">
> >> <Preload type="opensocial:rest" id="viewer" href="/people/@viewer...">
> >>
> >> Note that the REST urls dont carry an id parameter with them explicitly
> as
> >> RPC does so we would need to allow an optional id attribute to allow
> >> retrieval from DataResponse objects.
> >>
> >> A new XML sytax while perhaps a little prettier I dont think will do
> >> anything to improve adoption so I'd rather avoid creating another
> format.
> >>
> >> So my votes would be
> >>
> >> +1 JSON-RPC
> >> +0 for REST that acts like XRDS doesnt exist OR a new syntax
> >> -100 for REST with XRDS
> >>
> >>
> >>
> >>
> >> On Thu, Sep 18, 2008 at 3:37 PM, Kevin Brown <[EMAIL PROTECTED]> wrote:
> >>>
> >>> 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
> >>>>
> >>>>
> >>>
> >>>
> >>
> >> __._,_.___
> >> Messages in this topic (2) Reply (via web post) | Start a new topic
> >> Messages | Files | Photos | Links | Database | Polls | Members |
> Calendar
> >> Change settings via the Web (Yahoo! ID required)
> >> Change settings via email: Switch delivery to Daily Digest | Switch
> format
> >> to Traditional
> >> Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
> >> Recent Activity
> >>
> >> 5
> >> New Members
> >>
> >> Visit Your Group
> >> New web site?
> >>
> >> Drive traffic now.
> >>
> >> Get your business
> >>
> >> on Yahoo! search.
> >>
> >> Learn to live
> >>
> >> a full life with these
> >>
> >> healthy living
> >>
> >> groups on Yahoo!
> >>
> >> Y! Messenger
> >>
> >> All together now
> >>
> >> Host a free online
> >>
> >> conference on IM.
> >>
> >> .
> >> __,_._,___
> >
> > >
> >
>
> --~--~---------~--~----~------------~-------~--~----~
> 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
> -~----------~----~----~----~------~----~------~--~---
>
>
