Proposal for 0.8: JS API to allow mutation of newly created activities for coalescing

[Louis Ryan]

Hi,

With the current API it is difficult for gadgets to implement their own activity coalescing; gadgets must write their activities immediately rather than coalescing them because they cannot rely on onunload events, yet writing lots of activities is problematic asthey are constrained by application quotas etc.

See http://code.google.com/apis/orkut/docs/orkutdevguidelines.html#updates for some examples of why this is bad for developers and containers

I would like to propose that upon creation of an activity we return a handle to the gadget than can then be used to update the contents of that activity for a limited period of time to be defined as policy by the container.

Deferring syntax until I hear what people think about this.

-Louis

[Arne Roomann-Kurrik (Google)]

I like this idea. As I understand, this would at least require a
change to requestCreateActivity. Are you proposing a new
requestUpdateActivity function as well, or will requestCreateActivity
take a handle as an optional parameter?

Will there be the option to delete a created activity, given a
handle? Seems useful for cases where a gadget supplies an "undo"
functionality to users.

~Arne

On Apr 14, 1:19 pm, "Louis Ryan" <lr...@google.com> wrote:
> Hi,
>
> With the current API it is difficult for gadgets to implement their own
> activity coalescing; gadgets must write their activities immediately rather
> than coalescing them because they cannot rely on onunload events, yet
> writing lots of activities is problematic asthey are constrained by
> application quotas etc.
>

> Seehttp://code.google.com/apis/orkut/docs/orkutdevguidelines.html#update...

[Louis Ryan]

requestUpdateActivity is probably the most obvious choice but if people were strongly against a new method it could be accommodated within requestCreateActvitiy.

Specific proposed changes
- the ResponseItem passed to the callback on requestCreateActivity has its data field set to the actually created activity which has its ID field set. This is something that should happen anyway.
- newFetchActivitiesRequest returns activities with their ID field set

When requestCreateActivity is passed an Activity with an ID field it is treated as an update. Containers are free to constrain the update policy on activities as they see fit.

In the case where an update is denied the ReponseItem getErrorCode is set to LIMIT_EXCEEDED (proposal from other thread) The gadget may decide to attempt to post the additional data as a new activity rather than as an update in this case.

[do...@google.com]

I would like to close this thread for 0.8 and defer it until 0.9 as it
is not receiving enough feedback. (3 more people just need to jump in
asap if the community agrees that this should not wait)

Sites are free to implement this extra method as a container specific
extension in the meantime.
Thanks.

- Cassie