You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Kevin Brown <et...@google.com> on 2008/09/19 00:37:36 UTC
Re: [opensocial-and-gadgets-spec] Re: Declarative Data Definition
On Fri, Sep 19, 2008 at 12:14 AM, Adam Winer <aw...@gmail.com> wrote:
>
> On Thu, Sep 18, 2008 at 2:54 PM, Evan Gilbert <ui...@google.com> 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
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com<op...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
RE: [opensocial-and-gadgets-spec] Re: [os-templates] Re: [opensocial-and-gadgets-spec] Re: Declarative Data Definition
Posted by Scott Seely <SS...@myspace.com>.
Let's put this another way for the group.
We already know that being able to declaratively say what you want to do
instead of doing so imperatively (markup vs. code) is a Good Thing.
FaceBook has seen a lot of positive results from having a markup
language paired with their API. What a few of us did was take a look at
what FaceBook Markup Language does well, where it has shortcomings, and
then applied that knowledge for the shared markup for OpenSocial. The
result is the three part OSML proposal, currently in draft form at
http://wiki.opensocial-templates.org/index.php?title=Main_Page. OSML has
three parts:
1. OpenSocial Templating
<http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Templat
ing> :Open Social Template Part 1. A method for taking structured data
(object graphs) and rendering UI elements in an arbitrary markup. A
method for definining re-usable UI components that can be provided and
extended by Containers and Developers. A set of standard elements that
each Container implements. Client or server rendering depending on
context. Dependency: None.
2. OpenSocial Markup
<http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Markup>
:Open Social Template Part 2. A set of standard tags and behaviors that
utilize the above two technologies to provide the developer with a
simple, declarative language for putting apps together. A developer can
use it to create a simple, high performance application without a great
deal of conceptual ramp-up. OSML weaves Data and Templating together for
simplicity, but the developer can use the building blocks for more
complexity if needed.
3. OpenSocial Data Pipelining
<http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Data_Pi
pelining> : Open Social Template Part 3. A method for grabbing
OpenSocial and third-party data declaratively or in script and joining
it to templates. A way to take results from data calls and send them
back to the server (master-detail views). A method for paging and
filtering large lists. Client or server side. Bootstraps the current
DataRequest model for smooth compatibility and conceptual overlap.
Dependency: OpenSocial Templating.
This particular set of specs is different from FBML: they states not
only what will be provided but they also set some expectations about how
this functionality can be provided by containers.
Finally, OSML is currently proposed with a unique gadget feature name.
This means that a container that doesn't want to support OSML in all its
glory does not have to in order to be 'OpenSocial'. Everything that the
markup makes possible is also possible through JavaScript.
From: os-templates@yahoogroups.com [mailto:os-templates@yahoogroups.com]
On Behalf Of David Byttow
Sent: Friday, September 19, 2008 1:50 PM
To: opensocial-and-gadgets-spec@googlegroups.com
Cc: os-templates@yahoogroups.com; shindig-dev@incubator.apache.org
Subject: Re: [opensocial-and-gadgets-spec] Re: [os-templates] Re:
[opensocial-and-gadgets-spec] Re: Declarative Data Definition
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 <bo...@google.com>
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 <et...@google.com> wrote:
> On Fri, Sep 19, 2008 at 6:44 PM, Adam Winer <aw...@gmail.com> wrote:
>>
>> On Fri, Sep 19, 2008 at 9:22 AM, David Byttow
<da...@google.com>
>> 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 <lr...@google.com>
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 <et...@google.com>
wrote:
>> >>>
>> >>> On Fri, Sep 19, 2008 at 12:14 AM, Adam Winer <aw...@gmail.com>
wrote:
>> >>>>
>> >>>> On Thu, Sep 18, 2008 at 2:54 PM, Evan Gilbert
<ui...@google.com>
>> >>>> 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_Pip
elining
>> >>>>
>> >>>> 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
opensocial-and-gadgets-spec@googlegroups.com
To unsubscribe from this group, send email to
opensocial-and-gadgets-spec+unsubscribe@googlegroups.com
<ma...@googlegroups.com>
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/124;_ylc=X3oDMTMzY2F
1aWg1BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2d
JZAMxMzAEc2VjA2Z0cgRzbGsDdnRwYwRzdGltZQMxMjIxODU3Mzk1BHRwY0lkAzEyNA-->
(4) Reply (via web post)
<http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJwcmNqcXFuBF
9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2dJZAMxMz
AEc2VjA2Z0cgRzbGsDcnBseQRzdGltZQMxMjIxODU3Mzk1?act=reply&messageNum=130>
| Start a new topic
<http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJmZXRqcWRxBF
9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBH
NsawNudHBjBHN0aW1lAzEyMjE4NTczOTU->
Messages
<http://groups.yahoo.com/group/os-templates/messages;_ylc=X3oDMTJmYnVlNn
BlBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZn
RyBHNsawNtc2dzBHN0aW1lAzEyMjE4NTczOTU-> | Files
<http://groups.yahoo.com/group/os-templates/files;_ylc=X3oDMTJncG91cTJyB
F9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyB
HNsawNmaWxlcwRzdGltZQMxMjIxODU3Mzk1> | Photos
<http://groups.yahoo.com/group/os-templates/photos;_ylc=X3oDMTJmajl1ZjJm
BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRy
BHNsawNwaG90BHN0aW1lAzEyMjE4NTczOTU-> | Links
<http://groups.yahoo.com/group/os-templates/links;_ylc=X3oDMTJnNjFpaWUzB
F9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyB
HNsawNsaW5rcwRzdGltZQMxMjIxODU3Mzk1> | Database
<http://groups.yahoo.com/group/os-templates/database;_ylc=X3oDMTJkYzZiZG
41BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZn
RyBHNsawNkYgRzdGltZQMxMjIxODU3Mzk1> | Polls
<http://groups.yahoo.com/group/os-templates/polls;_ylc=X3oDMTJnaWsydHRlB
F9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyB
HNsawNwb2xscwRzdGltZQMxMjIxODU3Mzk1> | Members
<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJmZmE1ZXJ
rBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnR
yBHNsawNtYnJzBHN0aW1lAzEyMjE4NTczOTU-> | Calendar
<http://groups.yahoo.com/group/os-templates/calendar;_ylc=X3oDMTJlM3RvMm
k0BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZn
RyBHNsawNjYWwEc3RpbWUDMTIyMTg1NzM5NQ-->
Yahoo! Groups
<http://groups.yahoo.com/;_ylc=X3oDMTJlcDB2MTEyBF9TAzk3MzU5NzE0BGdycElkA
zIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTIyM
Tg1NzM5NQ-->
Change settings via the Web
<http://groups.yahoo.com/group/os-templates/join;_ylc=X3oDMTJnanB0OG0wBF
9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBH
NsawNzdG5ncwRzdGltZQMxMjIxODU3Mzk1> (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest
<mailto:os-templates-digest@yahoogroups.com?subject=Email%20Delivery:%20
Digest> | Switch format to Traditional
<mailto:os-templates-traditional@yahoogroups.com?subject=Change%20Delive
ry%20Format:%20Traditional>
Visit Your Group
<http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJlaHNncGo3BF9TAzk
3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawN
ocGYEc3RpbWUDMTIyMTg1NzM5NQ--> | Yahoo! Groups Terms of Use
<http://docs.yahoo.com/info/terms/> | Unsubscribe
<mailto:os-templates-unsubscribe@yahoogroups.com?subject=>
Recent Activity
* 6
New Members
<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJnMDE5ZHR
pBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnR
sBHNsawN2bWJycwRzdGltZQMxMjIxODU3Mzk1>
Visit Your Group
<http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJmams0bTlmBF9TAzk
3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnRsBHNsawN
2Z2hwBHN0aW1lAzEyMjE4NTczOTU->
Women of Curves
on Yahoo! Groups
<http://us.ard.yahoo.com/SIG=14kjj7bjs/M=493064.12016299.12445691.113227
65/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1221864595/L=/B=yPCYBkLaX.8-/J=1
221857395977115/K=n4PWll7gLtzWdqF.1OO3vg--/A=4990213/R=0/SIG=11odsb6gn/*
http:/new.groups.yahoo.com/Women_Of_Curves_Everywhere>
A positive group
to discuss Curves.
Weight Loss Group
on Yahoo! Groups
<http://us.ard.yahoo.com/SIG=14kobhold/M=493064.12016300.12445692.113231
96/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1221864595/L=/B=yfCYBkLaX.8-/J=1
221857395977115/K=n4PWll7gLtzWdqF.1OO3vg--/A=5170419/R=0/SIG=11b5gu1oe/*
http:/new.groups.yahoo.com/specialKgroup>
Get support and
make friends online.
Yahoo! Groups
Familyographer Zone
<http://us.ard.yahoo.com/SIG=14jedh1mj/M=493064.12717544.13024012.867457
8/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1221864595/L=/B=yvCYBkLaX.8-/J=12
21857395977115/K=n4PWll7gLtzWdqF.1OO3vg--/A=5370579/R=0/SIG=11lnr7bf1/*h
ttp:/advision.webevents.yahoo.com/familyographer/>
Learn how to capture
family moments.
.
<http://geo.yahoo.com/serv?s=97359714/grpId=22548568/grpspId=1705375618/
msgId=130/stime=1221857395/nc1=4990213/nc2=5170419/nc3=5370579>
__,_._,___
Re: [opensocial-and-gadgets-spec] Re: [os-templates] Re: [opensocial-and-gadgets-spec] Re: Declarative Data Definition
Posted by David Byttow <da...@google.com>.
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 <bo...@google.com> 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 <et...@google.com> wrote:
> > On Fri, Sep 19, 2008 at 6:44 PM, Adam Winer <aw...@gmail.com> wrote:
> >>
> >> On Fri, Sep 19, 2008 at 9:22 AM, David Byttow <da...@google.com>
> >> 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 <lr...@google.com> 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 <et...@google.com>
> wrote:
> >> >>>
> >> >>> On Fri, Sep 19, 2008 at 12:14 AM, Adam Winer <aw...@gmail.com>
> wrote:
> >> >>>>
> >> >>>> On Thu, Sep 18, 2008 at 2:54 PM, Evan Gilbert <ui...@google.com>
> >> >>>> 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
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com<op...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
Re: [opensocial-and-gadgets-spec] Re: [os-templates] Re: [opensocial-and-gadgets-spec] Re: Declarative Data Definition
Posted by Robert Evans <bo...@google.com>.
+1 using existing JSON/RPC and not implementing Yet Another Protocol
for OpenSocial.
On Fri, Sep 19, 2008 at 9:58 AM, Kevin Brown <et...@google.com> wrote:
> On Fri, Sep 19, 2008 at 6:44 PM, Adam Winer <aw...@gmail.com> wrote:
>>
>> On Fri, Sep 19, 2008 at 9:22 AM, David Byttow <da...@google.com>
>> 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 <lr...@google.com> 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 <et...@google.com> wrote:
>> >>>
>> >>> On Fri, Sep 19, 2008 at 12:14 AM, Adam Winer <aw...@gmail.com> wrote:
>> >>>>
>> >>>> On Thu, Sep 18, 2008 at 2:54 PM, Evan Gilbert <ui...@google.com>
>> >>>> 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
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
Re: [opensocial-and-gadgets-spec] Re: [os-templates] Re: [opensocial-and-gadgets-spec] Re: Declarative Data Definition
Posted by Kevin Brown <et...@google.com>.
On Fri, Sep 19, 2008 at 6:44 PM, Adam Winer <aw...@gmail.com> wrote:
>
> On Fri, Sep 19, 2008 at 9:22 AM, David Byttow <da...@google.com>
> 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 <lr...@google.com> 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 <et...@google.com> wrote:
> >>>
> >>> On Fri, Sep 19, 2008 at 12:14 AM, Adam Winer <aw...@gmail.com> wrote:
> >>>>
> >>>> On Thu, Sep 18, 2008 at 2:54 PM, Evan Gilbert <ui...@google.com>
> 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
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com<op...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
Re: [opensocial-and-gadgets-spec] Re: [os-templates] Re: [opensocial-and-gadgets-spec] Re: Declarative Data Definition
Posted by David Byttow <da...@google.com>.
On Fri, Sep 19, 2008 at 9:44 AM, Adam Winer <aw...@gmail.com> wrote:
>
> On Fri, Sep 19, 2008 at 9:22 AM, David Byttow <da...@google.com>
> 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.
>
Yes, that's right. The background on this being that OSML today can be used
on any container supporting the OS JS API with a single JS include. We want
to continue this trend with data-pipelining.
David
Re: [opensocial-and-gadgets-spec] Re: [os-templates] Re: [opensocial-and-gadgets-spec] Re: Declarative Data Definition
Posted by Adam Winer <aw...@gmail.com>.
On Fri, Sep 19, 2008 at 9:22 AM, David Byttow <da...@google.com> 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 <lr...@google.com> 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 <et...@google.com> wrote:
>>>
>>> On Fri, Sep 19, 2008 at 12:14 AM, Adam Winer <aw...@gmail.com> wrote:
>>>>
>>>> On Thu, Sep 18, 2008 at 2:54 PM, Evan Gilbert <ui...@google.com> 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
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
Re: [os-templates] Re: [opensocial-and-gadgets-spec] Re: Declarative Data Definition
Posted by David Byttow <da...@google.com>.
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 <lr...@google.com> 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 <et...@google.com> wrote:
>
>> On Fri, Sep 19, 2008 at 12:14 AM, Adam Winer <aw...@gmail.com> wrote:
>>
>>
>>> On Thu, Sep 18, 2008 at 2:54 PM, Evan Gilbert <ui...@google.com> 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
>> opensocial-and-gadgets-spec@googlegroups.com
>> To unsubscribe from this group, send email to
>> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com<op...@googlegroups.com>
>> 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<os-templates-digest@yahoogroups.com?subject=Email+Delivery:+Digest>| Switch
> format to Traditional<os-templates-traditional@yahoogroups.com?subject=Change+Delivery+Format:+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
> <os-templates-unsubscribe@yahoogroups.com?subject=>
> 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.
> .
>
> __,_._,___
>
Re: [opensocial-and-gadgets-spec] Re: Declarative Data Definition
Posted by John Panzer <jp...@google.com>.
There is the proposal to eliminate the variability in the URLs (jut allow a
variable prefix). It'd be good to get closure on those proposals so as to
not gum up proposals like these...
If that were in place, RESTful syntax would be the most natural way to pull
in content; it's just like an img tag:
<img src="./face.jpg"/>
vs.
<Preload href="./people/@owner..." ... />
(The idea being that Preload hrefs start from wherever the
container-specific path prefix ends, so a relative URL gets you the resource
you want.)
On Fri, Sep 19, 2008 at 9:17 AM, Louis Ryan <lr...@google.com> 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 <et...@google.com> wrote:
>
>> On Fri, Sep 19, 2008 at 12:14 AM, Adam Winer <aw...@gmail.com> wrote:
>>
>>
>>> On Thu, Sep 18, 2008 at 2:54 PM, Evan Gilbert <ui...@google.com> 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
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com<op...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
Re: [opensocial-and-gadgets-spec] Re: Declarative Data Definition
Posted by Louis Ryan <lr...@google.com>.
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 <et...@google.com> wrote:
> On Fri, Sep 19, 2008 at 12:14 AM, Adam Winer <aw...@gmail.com> wrote:
>
>
>> On Thu, Sep 18, 2008 at 2:54 PM, Evan Gilbert <ui...@google.com> 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
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com<op...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>