Adding support for lifecycle events (redux)
Paul Lindner
We're currently supporting this as:
http://www.hi5networks.com/developer/2008/04/addition-to-hi5lifecycle-invit.html
App developers really like this.
I believe there are MySpace extensions to do something similar..
If we can agree to a common syntax all the better...
----- Forwarded message from Paul Lindner <plin...@hi5.com> -----
Subject: [OpenSocial] Adding support for lifecycle events
Date: Wed, 6 Feb 2008 11:08:02 -0400
From: Paul Lindner <plin...@hi5.com>
To: opensoc...@googlegroups.com
Reply-To: opensoc...@googlegroups.com
Hi,
Us at hi5 would like to get feedback on a possible mechanism we could
use to pass lifecycle events to App writers. We propose that app
writers add the following to their gadget xml file:
<Optional feature="x-hi5-opensocial-lifecycle-0.0"/>
<Param name="view-remove">http://mysite.com/handleRemove</Param>
<Param name="view-add">http://mysite.com/handleAdd</Param>
<Param name="resource-exceeded">http://mysite.com/handleNaughty</Param>
...
</Optional>
This uses the new <Optional> and <Param> tags in the gadget spec.
When each event occurs in the container your backend will receive a
ping with some data related to the event. For example adding or
removing a gadget would get you the ID of the user and the view -- a
resource exhausted warning would give you details on the method that
is under restriction and when the restriction will be lifted.
We haven't finalized the ping format or the endpoint names. We'd
appreciate comments from app developers on what they think would be
worthwhile.
--
Paul Lindner
hi5 Architect
plin...@hi5.com
----- End forwarded message -----
--
Paul Lindner ||||| | | | | | | | | |
lin...@inuus.com
Louis Ryan
This is definitely something the Orkut team would like to see added
I think there are basically two classes of events, those which occur based on single user interaction and those that occur based on maintenance by the container. I'm assuming all of these should be signed calls.
Per user-events
install/add-view
uninstall/remove-view
permissions changed
quota/resource exceeded
Per-container events
App enabled
App disabled (reason = [policy violation | quota | system maintenance])
Lou Moore
We currently support install, uninstall, and invite. Again, see our blog for details:
http://www.hi5networks.com/developer/2008/04/addition-to-hi5lifecycle-invit.html
I agree with all the events Louis listed below. Additionally, this could be a method for reporting back data from request* methods that would work for containers doing asynchronous processing, as has been discussed on other threads. See our invite implementation, which could be extended to requestSendMessage as well.
We’re not married to the syntax we currently have.
-Lou
Kevin Brown
~Kevin
Amar Gandhi
From: opensocial-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of Kevin Brown
Sent: Monday, April 14, 2008 12:13 PM
To: opensocial-an...@googlegroups.com
Subject: Re: Adding support for lifecycle events (redux)
Zhen Wang
I suggest that we consider using <Link> tags (another v0.8 proposal)
to implement this feature (e.g. <Link rel="ping-on-removal"
href="http://..."/>)
Kevin Brown
+1
I suggest that we consider using <Link> tags (another v0.8 proposal)
to implement this feature (e.g. <Link rel="ping-on-removal"
href="http://..."/>)
I kind of like this, but we should use some light namespacing here to avoid naming collisions. event.add / event.remove etc.
--
~Kevin
Paul Lindner
> On Mon, Apr 14, 2008 at 3:44 PM, Zhen Wang <wa...@google.com> wrote:
>
> >
> > +1
> >
> > I suggest that we consider using <Link> tags (another v0.8 proposal)
> > to implement this feature (e.g. <Link rel="ping-on-removal"
> > href="http://..."/>)
>
>
> I kind of like this, but we should use some light namespacing here to avoid
> naming collisions. event.add / event.remove etc.
Ahh, very nice use of link tags. Agree about the namespace issue.
Now, what about the content of the events POSTed to the event
endpoint(s)? Obviously the events should be signed
Install/Remove App --> userid, appId, domain?
Invites Accepted --> userid list
--
Paul Lindner ||||| | | | | | | | | |
lin...@inuus.com
Nat Brown (ilike.com)
event sink
<Module>
<ModulePrefs
...
container_event_sink="http://my.domain.com/sink"
where arbitrary parameters of event=<event.named.fu> can be sent in
and i can ignore those events i don't care about. these events will
show up in my logs though, i could go back and handle events i missed
if one was added while i wasn't looking, and i could also route these
generically through some always-up-and-logging system so i don't miss
uninstals during maintenance (missed uninstall notifications happen
continuously on facebook).
yep, myspace has an uninstall URL we can specify in our spec.
lack of install/uninstall events has been pretty seriously lacking
here.
n@
>
> application_pgp-signature_part
> 1KDownload
Paul Walker
Excellent Paul!
My apologies for not catching your proposal for .7. We have set up an
event model for app developers and are queued to go with any sort of
events this group may come up with.
We will support any additional to the gadget xml for this, we currently
only make this available via our developer UI.
Louis - @MySpace we sign the request to the 3rd party servers the same
way we do with the makeRequest and I would add that as an important
unified security measure. Does anyone see an issue for this? I would
personally tread carefully on trying to categorize the events just yet.
I think we'll see greater use out of this "push" model.
I would add the ability to allow developers to define the request as
POST or GET along with parameters or standardize parameters per event
type. I dislike limiting to GET requests.
~Paul
Louis Ryan
The implementation detail choice seems to be one-endpoint (Nat) vs. multiple-endpoints. I dont see these as incompatible, i.e one endpoint for all events and then allow event specific overrides via namespacing, something like....
<Link rel="events" href="http://www.mysite.com/osevents"/>
<Link rel="events.install" href="http://www.mysite.com/installevents"/>
The other issue is categorization of events as part of the spec, there are a few outlined above but I'm pretty sure were missing some.
Heres what we have so far
Per user-events
add-app
add-app-from-invite (inviting user id is also passed as param)
remove-app
permissions changed
quota/resource exceeded
Per-container events
app-disabled (reason = [policy violation | quota | system maintenance])
Im assuming theres no need for a notification of an invite send as this can be achieved via makeRequest by the gadget itself?
-Louis
Lou
we'll put in place shortly.
Lou
>
> Im assuming theres no need for a notification of an invite send as this can
> be achieved via makeRequest by the gadget itself?
>
were actually sent. So I do think we need events for the request*
methods, unless there's some other proposal on the table to address
that.
-Lou
Paul Lindner
Here's a short writeup.
A container may optionally support sending lifecycle events to an
application developer's site by sending relevant query-params to a URL
endpoint. To receive these events you can place one or more link tags
in your app XML. Each link tag has a rel and href attribute. The
href attribute denotes the endpont where event pings are sent. If the
rel attribute is "opensocialevent" then all events are sent to that endpoint.
If the rel attribute matches "opensocialevent.TYPE" then events of TYPE are sent
to that endpoint. An optional method attribute can be set to POST or
GET to specify how the request should be sent. The default is GET.
Here are some examples
<link rel="event" href="http://www.example.com/pingme" method="POST/>
<link rel="event.addapp" href="http://www.example.com/add" />
<link rel="event.removeapp" href="http://www.example.com/remove" />
The following query-params will always be sent to the endpoint:
domain - the domain of the container implementing the change
appid - the appXML url
eventtype - the event type {addapp|removeapp| etc...}
SIGNED parameters will also be sent
[insert signed request verbiage here]
Most events will have information about one or more opensocial ID
values. These id values are passed as one or more id attributes.
Note that a single ping may aggregate a number of events by specifying
many id values.
The following event types are defined. Container custom events should
be designated with a domainname prefix to avoid namespace clashes.
addapp - Users that have installed the app (id)
Optional "from" designates how the user added this
app. Values are "invite", "gallery", "external"
removeapp - IDs of users that have removed the app
app - action={enabled|disabled|approved}
reason={policy|quota|maintenance} [Optional]
invite - id are people invited
from_id is the ID that sent the invitation.
On Thu, Apr 17, 2008 at 11:24:41AM -0700, Louis Ryan wrote:
> So it seems like were all in basic agreement on the mechanics (signing, link
> tags, namespacing etc.) +1 on POST option BTW.
>
> The implementation detail choice seems to be one-endpoint (Nat) vs.
> multiple-endpoints. I dont see these as incompatible, i.e one endpoint for
> all events and then allow event specific overrides via namespacing,
> something like....
>
> <Link rel="events" href="http://www.mysite.com/osevents"/>
> <Link rel="events.install" href="http://www.mysite.com/installevents"/>
>
> The other issue is categorization of events as part of the spec, there are a
> few outlined above but I'm pretty sure were missing some.
>
> Heres what we have so far
>
> *Per user-events*
> add-app
> add-app-from-invite (inviting user id is also passed as param)
> remove-app
> permissions changed
> quota/resource exceeded
>
>
> *Per-container events
> *app-enabled
> app-disabled (reason = [policy violation | quota | system maintenance])
>
> Im assuming theres no need for a notification of an invite send as this can
> be achieved via makeRequest by the gadget itself?
>
> -Louis
>
>
> On Thu, Apr 17, 2008 at 2:01 AM, Paul Walker <pwa...@myspace.com> wrote:
>
> >
> > +1
> >
> > Excellent Paul!
> >
> > My apologies for not catching your proposal for .7. We have set up an
> > event model for app developers and are queued to go with any sort of
> > events this group may come up with.
> >
> > We will support any additional to the gadget xml for this, we currently
> > only make this available via our developer UI.
> >
> > Louis - @MySpace we sign the request to the 3rd party servers the same
> > way we do with the makeRequest and I would add that as an important
> > unified security measure. Does anyone see an issue for this? I would
> > personally tread carefully on trying to categorize the events just yet.
> > I think we'll see greater use out of this "push" model.
> >
> > I would add the ability to allow developers to define the request as
> > POST or GET along with parameters or standardize parameters per event
> > type. I dislike limiting to GET requests.
> >
> > ~Paul
> >
> >
> >
> > From: opensocial-an...@googlegroups.com
> > [mailto:opensocial-an...@googlegroups.com] On Behalf Of Paul
> > Lindner
> > Sent: Tuesday, April 15, 2008 6:56 AM
> > To: opensocial-an...@googlegroups.com
> > Subject: Re: Adding support for lifecycle events (redux)
> >
> > On Mon, Apr 14, 2008 at 03:48:15PM -0700, Kevin Brown wrote:
> > > On Mon, Apr 14, 2008 at 3:44 PM, Zhen Wang <wa...@google.com> wrote:
> > >
> > > >
> > > > +1
> > > >
> > > > I suggest that we consider using <Link> tags (another v0.8 proposal)
> >
> > > > to implement this feature (e.g. <Link rel="ping-on-removal"
> > > > href="http://..."/>)
> > >
> > >
> > > I kind of like this, but we should use some light namespacing here to
> > > avoid naming collisions. event.add / event.remove etc.
> >
> > Ahh, very nice use of link tags. Agree about the namespace issue.
> >
> > Now, what about the content of the events POSTed to the event
> > endpoint(s)? Obviously the events should be signed
> >
> > Install/Remove App --> userid, appId, domain?
> > Invites Accepted --> userid list
> >
> >
> >
> > >
> >
>
> 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-an...@googlegroups.com
> To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
--
Paul Lindner ||||| | | | | | | | | |
lin...@inuus.com
Lou Moore
+1
Louis Ryan
There is another thread that is proposing exactly this I believe.
-Louis
Louis Ryan
One note: I think we can remove domain and appid from the list of explicit params as they are implicit in SIGNED requests
-Louis
Cassie
If you have any objections simply respond to this thread.
Thanks!
- Cassie