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
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://..."/>)
+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://..."/>)
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
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
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
+1