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/25 20:39:58 UTC
Re: [opensocial-and-gadgets-spec] RE: [os-templates] Declarative Data Definition - requirements
On Thu, Sep 25, 2008 at 8:29 PM, Scott Seely <SS...@myspace.com> wrote:
> It looks like the OSML spec has the person/people stuff figured out. For
> person/people, there is some information at
> http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Markup#.3Cos:PersonRequest.3E
> .
>
>
>
> <os:PersonRequest key="Viewer" id="VIEWER"
> fields="name,id,thumbnailUrl,books"/>
>
>
>
> <os:PeopleRequest key="PagedFriends" idSpec="VIEWER_FRIENDS" page="2"
> pageSize="20"/>
>
>
>
> We wouldn't need a new syntax for Person, People, Activities, or AppData as
> there is a different mapping independent of REST/XRDS.
>
>
>
> Does this solve the problem at hand? Is there a shortcoming in this
> solution that I'm not seeing?
>
The problem with this solution is that it's a 6th mapping for social data
(JSON-RPC, XML-RPC, JSON-REST, ATOM-REST, javascript APIs, and now this).
That's not really reasonable to expect developers to learn, especially since
different sites are going to support different things. Many people are
already frustrated at inconsistencies between implementations.
Re: [opensocial-and-gadgets-spec] Re: [os-templates] Declarative Data Definition - requirements
Posted by David Byttow <da...@google.com>.
On Thu, Sep 25, 2008 at 11:39 AM, Kevin Brown <et...@google.com> wrote:
>
> The problem with this solution is that it's a 6th mapping for social data
> (JSON-RPC, XML-RPC, JSON-REST, ATOM-REST, javascript APIs, and now this).
>
> That's not really reasonable to expect developers to learn, especially
> since different sites are going to support different things. Many people are
> already frustrated at inconsistencies between implementations.
>
> I don't see that as an effective argument against defining XML markup to
wrap one or more of the other protocols (e.g. the javascript APIs on the
client). A developer does not need to learn all 6 to build an app as they
can build a fairly compelling app right now with just the javascript APIs.
This is just a layer of abstraction with side-benefits of performance and
simplicity.
One of the primary goals of this is to support on the client and/or server
seamlessly such that a developer can worry less about whether or not it will
work on a given container.
David
Re: [opensocial-and-gadgets-spec] Re: [os-templates] Declarative Data
Definition - requirements
Posted by Evan Gilbert <ui...@google.com>.
Just to clarify, 1:1 mapping can mean any of the following things:
1. REST URL format (os:MakeRequest href="/people/@me")
2. Key/value params in URL format (os:MakeRequest
href="/people?person=@me"), very similar to 1
3. attribute/value pairs in XML element (os:PersonRequest person="@me')
4. JSON blob in XML (os:PersonRequest method="person" params="{person:
@me}">
etc...
I have strong opinions on which alternatives are better, but I think this is
a tangential discusison to the requirements.
On 9/25/08, Evan Gilbert <ui...@google.com> wrote:
>
> I was hoping not to get down to this level of detail yet - we have 6 other
> requirements to discuss and this discussion keeps overwhelming all other
> threads.
>
> I feel pretty strongly that the only actual requirement is a 1:1 mapping to
> REST/RPC. We might decide to have this be the identity mapping, but that can
> be part of the "what's the best way to implement the requirements"
> discussion.
>
> Evan
>
> On 9/25/08, Kevin Brown <et...@google.com> wrote:
>>
>> On Thu, Sep 25, 2008 at 8:29 PM, Scott Seely <SS...@myspace.com> wrote:
>>
>>> It looks like the OSML spec has the person/people stuff figured out.
>>> For person/people, there is some information at
>>> http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Markup#.3Cos:PersonRequest.3E
>>> .
>>>
>>>
>>>
>>> <os:PersonRequest key="Viewer" id="VIEWER"
>>> fields="name,id,thumbnailUrl,books"/>
>>>
>>>
>>>
>>> <os:PeopleRequest key="PagedFriends" idSpec="VIEWER_FRIENDS" page="2"
>>> pageSize="20"/>
>>>
>>>
>>>
>>> We wouldn't need a new syntax for Person, People, Activities, or AppData
>>> as there is a different mapping independent of REST/XRDS.
>>>
>>>
>>>
>>> Does this solve the problem at hand? Is there a shortcoming in this
>>> solution that I'm not seeing?
>>>
>>
>> The problem with this solution is that it's a 6th mapping for social data
>> (JSON-RPC, XML-RPC, JSON-REST, ATOM-REST, javascript APIs, and now this).
>>
>> That's not really reasonable to expect developers to learn, especially
>> since different sites are going to support different things. Many people are
>> already frustrated at inconsistencies between implementations.
>>
>> --~--~---------~--~----~------------~-------~--~----~
>> 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] Declarative Data Definition - requirements
Posted by Louis Ryan <lr...@google.com>.
I agree with all the requirements. I also feel strongly that we need 1:1 and
I think that should be achievable.
On Thu, Sep 25, 2008 at 12:04 PM, Evan Gilbert <ui...@google.com> wrote:
> I was hoping not to get down to this level of detail yet - we have 6 other
> requirements to discuss and this discussion keeps overwhelming all other
> threads.
>
> I feel pretty strongly that the only actual requirement is a 1:1 mapping to
> REST/RPC. We might decide to have this be the identity mapping, but that can
> be part of the "what's the best way to implement the requirements"
> discussion.
>
> Evan
>
>
> On 9/25/08, Kevin Brown <et...@google.com> wrote:
>>
>> On Thu, Sep 25, 2008 at 8:29 PM, Scott Seely <SS...@myspace.com> wrote:
>>
>>> It looks like the OSML spec has the person/people stuff figured out.
>>> For person/people, there is some information at
>>> http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Markup#.3Cos:PersonRequest.3E
>>> .
>>>
>>>
>>>
>>> <os:PersonRequest key="Viewer" id="VIEWER"
>>> fields="name,id,thumbnailUrl,books"/>
>>>
>>>
>>>
>>> <os:PeopleRequest key="PagedFriends" idSpec="VIEWER_FRIENDS" page="2"
>>> pageSize="20"/>
>>>
>>>
>>>
>>> We wouldn't need a new syntax for Person, People, Activities, or AppData
>>> as there is a different mapping independent of REST/XRDS.
>>>
>>>
>>>
>>> Does this solve the problem at hand? Is there a shortcoming in this
>>> solution that I'm not seeing?
>>>
>>
>> The problem with this solution is that it's a 6th mapping for social data
>> (JSON-RPC, XML-RPC, JSON-REST, ATOM-REST, javascript APIs, and now this).
>>
>> That's not really reasonable to expect developers to learn, especially
>> since different sites are going to support different things. Many people are
>> already frustrated at inconsistencies between implementations.
>>
>>
>>
>
> --~--~---------~--~----~------------~-------~--~----~
> 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] Declarative Data
Definition - requirements
Posted by Evan Gilbert <ui...@google.com>.
I was hoping not to get down to this level of detail yet - we have 6 other
requirements to discuss and this discussion keeps overwhelming all other
threads.
I feel pretty strongly that the only actual requirement is a 1:1 mapping to
REST/RPC. We might decide to have this be the identity mapping, but that can
be part of the "what's the best way to implement the requirements"
discussion.
Evan
On 9/25/08, Kevin Brown <et...@google.com> wrote:
>
> On Thu, Sep 25, 2008 at 8:29 PM, Scott Seely <SS...@myspace.com> wrote:
>
>> It looks like the OSML spec has the person/people stuff figured out.
>> For person/people, there is some information at
>> http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Markup#.3Cos:PersonRequest.3E
>> .
>>
>>
>>
>> <os:PersonRequest key="Viewer" id="VIEWER"
>> fields="name,id,thumbnailUrl,books"/>
>>
>>
>>
>> <os:PeopleRequest key="PagedFriends" idSpec="VIEWER_FRIENDS" page="2"
>> pageSize="20"/>
>>
>>
>>
>> We wouldn't need a new syntax for Person, People, Activities, or AppData
>> as there is a different mapping independent of REST/XRDS.
>>
>>
>>
>> Does this solve the problem at hand? Is there a shortcoming in this
>> solution that I'm not seeing?
>>
>
> The problem with this solution is that it's a 6th mapping for social data
> (JSON-RPC, XML-RPC, JSON-REST, ATOM-REST, javascript APIs, and now this).
>
> That's not really reasonable to expect developers to learn, especially
> since different sites are going to support different things. Many people are
> already frustrated at inconsistencies between implementations.
>
> --~--~---------~--~----~------------~-------~--~----~
> 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
> -~----------~----~----~----~------~----~------~--~---
>
>