Fixes to the OSML spec

[awi...@gmail.com]

http://codereview.appspot.com/32044/diff/1/2
File draft/OpenSocial-Markup-Language-Tags.xml (left):

http://codereview.appspot.com/32044/diff/1/2#oldcode61
Line 61: Inline tag to show a person's name, linked if the a profile URL
an may have additional container bling (i.e. more information on hover)
need some grammar fixes in this line.

http://codereview.appspot.com/32044/diff/1/2
File draft/OpenSocial-Markup-Language-Tags.xml (right):

http://codereview.appspot.com/32044/diff/1/2#newcode83
Line 83: <t>@person {string|Object} The person object or DataContext key
referring to a
Think this should always be a Person object.
Supporting a DataContext key just saves you the ${} braces.

http://codereview.appspot.com/32044/diff/1/2#newcode89
Line 89: Welcome, &lt;script type="text/os-template"
xmlns:os="http://ns.opensocial.org/2008/markup"&gt;&lt;os:Name
person="${Viewer}"/&gt;&lt;/script&gt;
would probably put the script around the whole thing (don't want people
thinking we're *totally* crazy with that script element)

http://codereview.appspot.com/32044/diff/1/2#newcode101
Line 101: <t>@group {string|Object} An array of person objects or
DataContext key referring to an array
ditto

http://codereview.appspot.com/32044/diff/1/2#newcode109
Line 109: <t>@onselect {string|function} Client side script function to
invoke when a person
what can the script do? what arguments does it take? When is it called
for multiple selection? We might punt this out of the spec and make it
a container extension, or we can try fully specifying it.

http://codereview.appspot.com/32044/diff/1/2#newcode218
Line 218: <t>Then use ${Data} in your template.</t>
need <os:Html code="${Data}"/> if the request includes any markup.

http://codereview.appspot.com/32044

[Adam Winer]

2009/3/26 <opensoc...@gmail.com>

http://codereview.appspot.com/32044/diff/1/2
File draft/OpenSocial-Markup-Language-Tags.xml (right):

http://codereview.appspot.com/32044/diff/1/2#newcode83
Line 83: <t>@person {string|Object} The person object or DataContext key
referring to a

On 2009/03/27 00:26:17, awiner wrote:

Think this should always be a Person object.
Supporting a DataContext key just saves you the ${} braces.

Agree with Adam on this.

http://codereview.appspot.com/32044/diff/1/2#newcode109
Line 109: <t>@onselect {string|function} Client side script function to
invoke when a person

On 2009/03/27 00:26:17, awiner wrote:

what can the script do?  what arguments does it take?  When is it

called for

multiple selection?  We might punt this out of the spec and make it a

container

extension, or we can try fully specifying it.

Think the callback should be either:
1. callback(idsOfPeople) or
2. callback(listOfPeopleObjects)

#1 probably makes sense given server side rendering - you don't want to
have to keep the people around. But #2 would make it easier to do
something with the selected people without looking them up.

Either's fine by me.  Any chance though of just listening on the field that this is updating? 

http://codereview.appspot.com/32044/diff/1/2#newcode218
Line 218: <t>Then use ${Data} in your template.</t>

On 2009/03/27 00:26:17, awiner wrote:

need <os:Html code="${Data}"/> if the request includes any markup.

There was a long discussion which ended in having <os:Get>, and I only
want to reverse the decision and remove the tag if we have agreement
from all folks who wanted the the functionality (MySpace/Yahoo folks -
please review this)

<os:Get> supports repeated and conditional download of data, so we lose
some functionality in the other constructs.

The concern here is that repeated download of data is functionality I *want* to lose.  Pipelining download is tightly controlled and analyzable (it's easy to fetch all the data up front and be done).  os:Get is not, since it lives anywhere.

Think it's OK for the client side implementation and/or Shindig
server-side implementation to be naive and slow (deferred load via JS) -
if developers like the feature we can then improve performance.

I'm highly reluctant to claim any support for a feature that is extremely slow without a clear path to making it not slow - and I can't see any way around repeated download of (tens of?) HTML fragments being anything other than slow.  Any use would also have to be tightly controlled to avoid turning OSML into DoS-omatic:

  <os:Repeat expression="${Top.Friends}" index="a">

    <os:Repeat expression="${Top.Friends}" index="b">

      <os:Repeat expression="${Top.Friends}" index="c">

        <os:Repeat expression="${Top.Friends}" index="d">

          <os:Get href="http://example.org/diediedie?v=${a+100*(b+100*(c+(100*d))))}"/>

   etc...

Given that the OSML spec says containers must implement all tags, if we have containers that do not want this tag, I think the tag shouldn't be in the spec, or should be an optional part of the spec.  Containers that want it are always free to add it as an extension, and prove its utility to the doubters with deployed code.  I do agree that MySpace/Yahoo should weigh in, as should any other containers that want this or don't want this.

-- Adam

http://codereview.appspot.com/32044

[Evan Gilbert]

makeRequest() is equivalently DoS capable. We all should be throttling per app on the server side, and we can put a maximum of N requests from the client in the JS (developer could override, but we can make that a policy violation).

Also, we can batch these requests up on the client by setting timeout(0) instead of automatically sending to the server. This might be a simpler way to throttle - we just reject requests that have more than N items in the batch.

[Scott Seely]

Have we got an updated version of these edits?

[Lev Epshteyn]

I'm out of town for the weekend with only my ipod for computing, so
i'll merge in all the feedback on tuesday when i'm back at the office.

> <http://example.org/diediedie?v=$%7Ba+100*%28b+100*%28c+%28100*d%29%29%2
> 9%29%7D> "/>

[Lev Epshteyn]

I updated the patch based on the discussion.

For <os:PeopleSelector> I decided it made the most sense to operate on Person Objects, since the OSML control would get fed in through Data Pipelining, and the Objects would have to be available on the client anyway.

[Charlie Jiang]

Sorry to chime in late on os:Get. I agree with Evan that os:Get is not quite just a duplicate of os:httpRequest and os:hml. We should keep the os:Get for the simplicity and additional functionalities.

 

-Charlie

---

[Adam Winer]

Charlie,

Can you go into more detail? I've stated a number of concrete
objections, and would appreciate a more detailed reply to those
objections.

Specifically:
- os:Get within a loop is necessarily slow, and cannot be analyzed a
priori to determine how many HTTP requests a gadget will produce.
- os:Get cannot be prefetched at the same time as Data Pipelining, and
therefore hurts latency.
- os:Get (as defined) lacks all of the knobs that os:HttpRequest does
(signing, caching, oauth, etc.)
- os:Get can be implemented as an extension by containers to prove
that it is specifically useful; to the best of my knowledge, there is
not yet even a prototype in use by developers.

Could you reply to each of these?

Regards,
Adam Winer

[Louis Ryan]

Charlie

I heartily echo Adams comments. os:Get is at best an incremental optimization over proxied-renders. I strongly suspect that os:HttpRequest will more than meet any requirements.

-Louis 

[Charlie Jiang]

Looking into your detailed objections, here are my takes:

- os:Get within a loop is necessarily slow, and cannot be analyzed a
priori to determine how many HTTP requests a gadget will produce.

I think we are aware that the added functionality is at the cost of performance. The developer has to make the decision whether in its application this feature worth the trade off. On the other hand, there are spaces to optimize later on the implementation to increase the parallel behaviors.

- os:Get cannot be prefetched at the same time as Data Pipelining, and
therefore hurts latency.

Again, this actually solved the dependency issue that data pipeline is not solving. I don't think you can solve the dependency without serializing dependent http requests.

- os:Get (as defined) lacks all of the knobs that os:HttpRequest does
(signing, caching, oauth, etc.)

This is the first version of it, I believe Evan want to be conservative at this point.

- os:Get can be implemented as an extension by containers to prove
that it is specifically useful; to the best of my knowledge, there is
not yet even a prototype in use by developers.

I am actually open to reduce the step. As long as Shindig has a prototype implementation to let both containers and developers test the benefit and drawback of this tag, we are ok.

-Charlie

---

From: Louis Ryan
To: opensocial-an...@googlegroups.com
Cc: Charlie Jiang; Scott Seely ; opensoc...@gmail.com
Sent: Tue Mar 31 20:44:05 2009
Subject: Re: [opensocial-and-gadgets-spec] Re: Fixes to the OSML spec

[Adam Winer]

On Tue, Mar 31, 2009 at 9:11 PM, Charlie Jiang <cji...@yahoo-inc.com> wrote:

Looking into your detailed objections, here are my takes:

- os:Get within a loop is necessarily slow, and cannot be analyzed a
priori to determine how many HTTP requests a gadget will produce.

I think we are aware that the added functionality is at the cost of performance. The developer has to make the decision whether in its application this feature worth the trade off. On the other hand, there are spaces to optimize later on the implementation to increase the parallel behaviors. 

But because it's simpler - one tag vs. two - developers will prefer the slower version.  That's discouraging.

 

- os:Get cannot be prefetched at the same time as Data Pipelining, and
therefore hurts latency.

Again, this actually solved the dependency issue that data pipeline is not solving. I don't think you can solve the dependency without serializing dependent http requests.

Data pipelining in Shindig already supports dependencies, so that's a moot point.  It's not in the 0.9 spec because we were being conservative about implementations, but it's 100% possible to solve. 

- os:Get (as defined) lacks all of the knobs that os:HttpRequest does
(signing, caching, oauth, etc.)

This is the first version of it, I believe Evan want to be conservative at this point.

... and there are advantages to forcing it to be cacheable resources only, so on that point I'm OK.

 

- os:Get can be implemented as an extension by containers to prove
that it is specifically useful; to the best of my knowledge, there is
not yet even a prototype in use by developers.

I am actually open to reduce the step. As long as Shindig has a prototype implementation to let both containers and developers test the benefit and drawback of this tag, we are ok.

Would you like to contribute the patch?

Again: I'm not seeing arguments that say this contributes functionality so essential that it deserves duplicate mechanisms.  I'm happy for container developers that believe in it - Yahoo, for one - to pursue this as an extension, and contribute developer feedback into the spec.  But I don't see the reason to require all container developers to implement this, and that's what's being discussed here.  Not "could this be a good idea?" but "should all containers implement it?".

-- Adam

[goosemanjack]

This tag (originally proposed back in November as os:RenderRequest) is
specifically designed to be simple. HTML fragment rendering is a very
common technique in modern Ajax-y web apps. If there is strong
opposition we (MySpace) will implement as a proprietary extension for
this version, but it's inclusion was a compromise made when we agreed
to allow proxied content blocks into the spec.

>
> > - os:Get (as defined) lacks all of the knobs that os:HttpRequest does
> > (signing, caching, oauth, etc.)
>

<snip>

>
> But because it's simpler - one tag vs. two - developers will prefer the
> slower version. That's discouraging.
>

This argument (including a simpler implementation of alternately
available functionality) already has precedent in the 0.9 spec.
Specifically, it was the argument used by shindig for making the
addition of attribute-based flow control for Repeat and If when the
os:Render and os:If tags were already part of the spec.
--
clc


<snip>

[Scott Seely]

The OpenSocial community had a lot of discussions around these use cases
in October and November 2008. Given the strong feelings on both sides
and the specific needs of our community, we decided to have the two
mechanisms.

The reason to remove the tag should be based on implementation
experience and a consensus by the community that the whole community
agrees. Such a removal happened already with UserPreferences
incorporation into REST because we all agreed. Agreement is not
happening now, after several days of discussion and both sides making
their cases.

Given that opinions have not changed since November, I request that we
leave things as is.

> -----Original Message-----
> From: opensocial-an...@googlegroups.com
[mailto:opensocial-and-
> gadget...@googlegroups.com] On Behalf Of goosemanjack
> Sent: Wednesday, April 01, 2009 9:35 AM
> To: OpenSocial - OpenSocial and Gadgets Specification Discussion
> Subject: [opensocial-and-gadgets-spec] Re: Fixes to the OSML spec
>
>

[Evan Gilbert]

Scott / Chris / Charlie - Would you be comfortable having a common extension tag for this? <os:xGet> (or something similar)?

The biggest concern from the Google side is supporting this tag at scale - it creates the fan-out problem when used in loops, and the dynamic nature of the tag content means that we can't make it the requested data part of preloaded data. Everyone is in favor of having a standard way for containers to expose this functionality if supported, but Google will not be able support it in all cases.

So either an extension tag or making support for <os:Get> optional would meet our goals.

[Scott Seely]

+1 for optional.

[Lev Epshteyn]

+1

[goosemanjack]

+1

On Apr 1, 6:36 pm, Lev Epshteyn <le...@google.com> wrote:
> +1
>
> On Wed, Apr 1, 2009 at 4:38 PM, Scott Seely <sSe...@myspace.com> wrote:
> >  +1 for optional.
>

> > *From:* opensocial-an...@googlegroups.com [mailto:
> > opensocial-an...@googlegroups.com] *On Behalf Of *Evan Gilbert
> > *Sent:* Wednesday, April 01, 2009 1:18 PM
> > *To:* opensocial-an...@googlegroups.com
>
> > *Subject:* [opensocial-and-gadgets-spec] Re: Fixes to the OSML spec

[Louis Ryan]

+1

[Lev Epshteyn]

So I think we are all in agreement - we will strive for an available implementation of a Get-like tag in Shindig, but it may be turned off by default. But it won't be in the spec as yet.

I think everyone's on board - Arne, can you push?

[Arne Roomann-Kurrik]

Committed at http://code.google.com/p/opensocial-resources/source/detail?r=1081

~Arne

--
OpenSocial IRC - irc://irc.freenode.net/opensocial

[Charlie Jiang]

+1 as optional.

 

(Just came back to office today.)

 

---

From: opensocial-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of Evan Gilbert

Sent: Wednesday, April 01, 2009 1:18 PM
To: opensocial-an...@googlegroups.com