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