Are you referring to using the JSON/RPC protocol for underpinning a
declarative declaration or something else? I'm not sure that anyone has
declared that we define a new protocol for OpenSocial. But we do want to
create a declarative model for fetching data that can be piped into
templates. It's just in our best interest to see where we can align those
requirements with the requirements for preloading data.
On Fri, Sep 19, 2008 at 12:33 PM, Robert Evans <[EMAIL PROTECTED]> wrote:
>
> +1 using existing JSON/RPC and not implementing Yet Another Protocol
> for OpenSocial.
>
> On Fri, Sep 19, 2008 at 9:58 AM, Kevin Brown <[EMAIL PROTECTED]> wrote:
> > 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
> -~----------~----~----~----~------~----~------~--~---
>
>
