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.
- Must be able to associate a string key with any given data request.
- Must be able to parametrize a data request (i.e., <os:PeopleRequest ...
page="${page}">)
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.
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
>>>
>>>
>>>
>> --~--~---------~--~----~------------~-------~--~----~
>> 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
>> -~----------~----~----~----~------~----~------~--~---
>>
>>
> __._,_.___ Messages in this topic
> <http://groups.yahoo.com/group/os-templates/message/120;_ylc=X3oDMTMzNXJiZXNvBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2dJZAMxMjIEc2VjA2Z0cgRzbGsDdnRwYwRzdGltZQMxMjIxODQxMDM5BHRwY0lkAzEyMA-->(
> 2) Reply (via web post)
> <http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJwaTNjbGthBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2dJZAMxMjIEc2VjA2Z0cgRzbGsDcnBseQRzdGltZQMxMjIxODQxMDM5?act=reply&messageNum=122>|
> Start
> a new topic
> <http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJmcHUxcGprBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEyMjE4NDEwMzk->
>
> Messages<http://groups.yahoo.com/group/os-templates/messages;_ylc=X3oDMTJmbmhxNTduBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNtc2dzBHN0aW1lAzEyMjE4NDEwMzk->|
> Files<http://groups.yahoo.com/group/os-templates/files;_ylc=X3oDMTJnYjQ1cDNxBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNmaWxlcwRzdGltZQMxMjIxODQxMDM5>|
> Photos<http://groups.yahoo.com/group/os-templates/photos;_ylc=X3oDMTJmc2E2MWI3BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNwaG90BHN0aW1lAzEyMjE4NDEwMzk->|
> Links<http://groups.yahoo.com/group/os-templates/links;_ylc=X3oDMTJnZmZ1Y2huBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNsaW5rcwRzdGltZQMxMjIxODQxMDM5>|
> Database<http://groups.yahoo.com/group/os-templates/database;_ylc=X3oDMTJkNWUwZDhsBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNkYgRzdGltZQMxMjIxODQxMDM5>|
> Polls<http://groups.yahoo.com/group/os-templates/polls;_ylc=X3oDMTJnb3EyM3NnBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNwb2xscwRzdGltZQMxMjIxODQxMDM5>|
> Members<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJmdHZnaWVtBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNtYnJzBHN0aW1lAzEyMjE4NDEwMzk->|
> Calendar<http://groups.yahoo.com/group/os-templates/calendar;_ylc=X3oDMTJldmoyOW1sBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNjYWwEc3RpbWUDMTIyMTg0MTAzOQ-->
> [image: Yahoo!
> Groups]<http://groups.yahoo.com/;_ylc=X3oDMTJldmk4czhiBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTIyMTg0MTAzOQ-->
> Change settings via the
> Web<http://groups.yahoo.com/group/os-templates/join;_ylc=X3oDMTJnczAwdGM5BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNzdG5ncwRzdGltZQMxMjIxODQxMDM5>(Yahoo!
> ID required)
> Change settings via email: Switch delivery to Daily Digest<[EMAIL
> PROTECTED]:+Digest>| Switch
> format to Traditional<[EMAIL PROTECTED]:+Traditional>
> Visit Your Group
> <http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJlcWx0dW4zBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNocGYEc3RpbWUDMTIyMTg0MTAzOQ-->|
> Yahoo!
> Groups Terms of Use <http://docs.yahoo.com/info/terms/> | Unsubscribe
> <[EMAIL PROTECTED]>
> Recent Activity
>
> - 5
> New
> Members<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJnNzJhdnIxBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxMjIxODQxMDM5>
>
> Visit Your Group
> <http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJmcTJ1ZDIxBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzEyMjE4NDEwMzk->
> New web site?
>
> Drive traffic
> now.<http://us.ard.yahoo.com/SIG=13ok44h8u/M=493064.12016308.12445700.8674578/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1221848239/L=/B=LnJpGELaX.w-/J=1221841039841429/A=3848642/R=0/SIG=131eshi2t/*http://searchmarketing.yahoo.com/arp/srchv2.php?o=US2004&cmp=Yahoo&ctv=Groups3&s=Y&s2=&s3=&b=50>
>
> Get your business
>
> on Yahoo! search.
> Learn to live
>
> a full life with
> these<http://us.ard.yahoo.com/SIG=13oohqpc4/M=493064.12662709.12980595.8674578/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1221848239/L=/B=L3JpGELaX.w-/J=1221841039841429/A=5349281/R=0/SIG=11ks6tatn/*http://advision.webevents.yahoo.com/HealthyLiving/>
>
> healthy living
>
> groups on Yahoo!
> Y! Messenger
>
> All together
> now<http://us.ard.yahoo.com/SIG=13oatldft/M=493064.12016274.12445679.8674578/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1221848239/L=/B=MHJpGELaX.w-/J=1221841039841429/A=3848585/R=0/SIG=12ceqob45/*http://us.rd.yahoo.com/evt=42403/*http://messenger.yahoo.com/feat_conf.php>
>
> Host a free online
>
> conference on IM.
> .
>
> __,_._,___
>
