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