Proposal for 0.8 : additional field LIMIT_EXCEEDED opensocial.ResponseItem.Error

[Brandon]

The opensocial.ResponseItem.Error currently exposes several static
fields to indicate to the developer what sort of error occurred:
http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.ResponseItem.Error.html

We propose adding an additional field, LIMIT_EXCEEDED to indicate to
the developer that their application has exceeded some throttling
limit and this is why the call cannot be processed at this time. We
plan on enforcing limits on gadgets (calls per day, calls per user per
day, burst limits, etc) and we think it's useful to differentiate this
from other error codes.
The developer may respond to this error by retrying the call later,
failing gracefully, etc.

We had considered the need to make this return code more informative,
for example telling the developer what particular limit that was
exceeded, or how long the gadget must wait before this call will
succeed but in the end we believe it's only necessary to let the
gadget know that the call failed because some limit was exceeded.

[Cassie]

associated spec change:


opensocial.ResponseItem.Error = {
...

  /**
   * The gadget passed a quota on the request. Example quotas include a
   * max number of calls per day, calls per user per day, calls within a
   * certain time period and so forth.
   *
   * @member opensocial.ResponseItem.Error
   */
  LIMIT_EXCEEDED : 'limitExceeded',

...

[Cassie]

Does anybody have any comments on this change? It is a candidate for
0.8 which needs more feedback.

- Cassie

[Louis Ryan]

+1

Orkut has been using BAD_REQUEST until now for this situation which is far from ideal, the reason we havent received any feedback for this yet is because our quotas are so high that developers arent seeing the impact yet. I fully expect that when we tighten up this issue will become more important.

I think we also need to cleanup the documentation for BAD_REQUEST, perhaps something like 'The content or structure of the request is invalid'

Anyone else?

[Arne Roomann-Kurrik]

+1 for more detailed error messages in general. 

~Arne

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

[Chad Russell]

Hi, here at MySpace we’re not really using gadgets.views.ViewType as DASHBOARD doesn’t really work for us.  We have a “home” page and a “profile” page, both of which can host apps, but both fall under the definition of DASHBOARD.  The home page is user facing (private) while the profile page is public facing.

 

So can I propose breaking DASHBOARD up into two, which would make gadgets.views.ViewType something like this:

 

PUBLIC_DASHBOARD

PRIVATE_DASHBOARD

FULL_PAGE

POPUP

 

Not sure exactly who else supports something like this, so feedback is appreciated.

 

Thanks!

Chad Russell

crus...@myspace.com

 

 

[Reinoud Elhorst]

At Hyves we'll be support homepage/private dashboard gadgets as well.

Are these values 1:1 related to the <content view=...> tags?

[Cassie]

+1
Okay, Brandon, Louis, Arne and I are all +1. Will 1 more person chime in here?

Thanks.
- Cassie

[Oleg Pylnev]

+1

 

-Oleg

[Cassie]

Approved for opensocial 0.8

- Cassie

[Marco Ensing]

+1

With allowing different limitations on different requests.

> > cruss...@myspace.com- Hide quoted text -
>
> - Show quoted text -

[Cassie]

Chad - I think eventually all of these enums are probably going to need an overhaul. The current status of views is something like this:

orkut: profile, canvas
myspace: profile, canvas, home (i think?)
igoogle: home, canvas
hi5: profile, preview, canvas

which, if you notice doesn't match up -at all- with those enums.
how about if we just change the enum to reflect reality:

- home - private page with multiple apps, viewer=owner
- profile - public page with multiple apps, viewer does not have to = owner
- canvas - public page with a single app, viewer does not have to = owner
- preview - a "demo" page. owner == viewer == null

what does everyone think about this?
thanks.

- cassie

[David Glazer]

+1 (both to the "pave over the paths of dead grass" approach to sidewalk placement, and to the specific suggestion)

[Chris Chabot]

+1

Was wondering how we would deal with this; Will make life easier for
SNS- & gadget developers alike.

-- Chris

[Chad Russell]

+1, looks good to me!

-----Original Message-----
From: opensocial-an...@googlegroups.com
[mailto:opensocial-an...@googlegroups.com] On Behalf Of Chris
Chabot
Sent: Monday, April 28, 2008 6:20 AM
To: opensocial-an...@googlegroups.com

[Dan Peterson]

+1 from me as well -- glad we've been able to iterate to a cleaner definition of these enums.

 

For the docs, the "multiple apps" part may vary from container -- for example, some containers may only allow 1 app on a "home" page. It seems lke it should be 1-N depending upon the container's policy.

 

-Dan
 

[Cassie]

Alright, this spec change is approved.
Dan - I can clean up some of the wording and format of the spec change itself and it will all go out for review when we have the entire diff for 0.8

Thanks.

- Cassie