Online PRESENCE Proposal

[Paul Lindner]

Hi,

I'd like to see the following added to the next opnesocial spec:

A new field for Person named PRESENCE, defined as an Enum

ONLINE "Online"
OFFLINE "Offline"
DND "Do Not Disturb"

Patches to shindig are available for
socialdata servlet
opensocial-0.7 jsonperson.js
etc.

--
Paul Lindner ||||| | | | | | | | | |
lin...@inuus.com

[Kevin Brown]

I like this idea, but I'd also like to eventually make opensocial work with XMPP to support real time communication between users as a standard feature, which would make some of this redundant. I know a lot of people have had ideas around this, but it's never really gone anywhere so far.

--
~Kevin

[Lou]

+1

I also think that a presence filter, ONLINE (or any of the enums paul
suggested) makes sense for PEOPLE fetches. This is a better way to get
a list of your online friends that we currently have in our hi5
feature, which adds a hi5.fetchPresenceRequest. We'd like to deprecate
that in favor of a filter and get that into the spec.

-Lou

> lind...@inuus.com
>
>  application_pgp-signature_part
> 1KDownload

[Paul Lindner]

Okay, I suppose we can adopt the nomenclature specified in section 2.2.2 of the XMPP protocol:

In that case we’d have an enum of the following:
  offline (not specified in protocol.)
  online (notspecified, it’s the default)
   o  away -- The entity or resource is temporarily away.
   o  chat -- The entity or resource is actively interested in chatting.
   o  dnd -- The entity or resource is busy (dnd = "Do Not Disturb").
   o  xa -- The entity or resource is away for an extended period (xa =
      "eXtended Away").

And the display text for the enum could correspond to section 2.2.2.2 (status message)

[Dan Brickley]

+cc: Peter Saint-Andre

On Fri, Mar 28, 2008 at 11:01 PM, Kevin Brown <et...@google.com> wrote:
> I like this idea, but I'd also like to eventually make opensocial work with
> XMPP to support real time communication between users as a standard feature,
> which would make some of this redundant. I know a lot of people have had
> ideas around this, but it's never really gone anywhere so far.

Maybe this is a good point to pop up and plug the new 'social' list
set up recently, soc...@xmpp.org,
details here: http://mail.jabber.org/mailman/listinfo/social

List blurb: The mashup of Web and Jabber! OpenID, OAuth, buddy lists
beyond IM, XMPP pubsub instead of HTTP polling, etc.

See also the http://mail.jabber.org/mailman/listinfo/api list which as
I understand it from
http://mail.jabber.org/pipermail/api/2008-February/000001.html is
focussed on .js APIs for XMPP in widgety contexts (and therefore a bit
more tightly scoped than the social@ list).

cheers,

Dan

--
http://danbri.org/

[Julian Bond]

Paul Lindner <plin...@hi5.com> Fri, 28 Mar 2008 16:24:38

>And the display text for the enum could correspond to section 2.2.2.2
>(status message)

Some comments.
- IM systems tend to have at least 5 or 6 possible online presence
values
- There's a trend towards rich presence that includes quite a bit more
than just online status
- Does Presence also include current location?
- How about preferred current communication method. eg Phone, SMS, IM,
- Most every social network now has a Twitter-like Status field, just as
most IM systems have a status message or mood.
- Some of this stuff begins to look like a life-stream once you add in
things like currently listening to.
- Then there's near future status. I'm currently here, doing this,
online. This evening I'll be there, doing that, on SMS only.

--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat
Always Replace The Cap

[Kevin Brown]

On Sun, Mar 30, 2008 at 12:39 AM, Julian Bond <julia...@voidstar.com> wrote:

Paul Lindner <plin...@hi5.com> Fri, 28 Mar 2008 16:24:38

>And the display text for the enum could correspond to section 2.2.2.2
>(status message)

Some comments.
- IM systems tend to have at least 5 or 6 possible online presence
values
- There's a trend towards rich presence that includes quite a bit more
than just online status
- Does Presence also include current location?
- How about preferred current communication method. eg Phone, SMS, IM,
- Most every social network now has a Twitter-like Status field, just as
most IM systems have a status message or mood.
- Some of this stuff begins to look like a life-stream once you add in
things like currently listening to.
- Then there's near future status. I'm currently here, doing this,
online. This evening I'll be there, doing that, on SMS only.

This could always just be an object with numerous properties, as in:

presence: {
  status: "online",
  statusMessage: "I'm not home right now...",
  ...other fields...
}

Easily maps in the REST API as well.

--
Julian Bond  E&MSN: julian_bond at voidstar.com  M: +44 (0)77 5907 2173
Webmaster:          http://www.ecademy.com/      T: +44 (0)192 0412 433
Personal WebLog:    http://www.voidstar.com/     skype:julian.bond?chat
                        Always Replace The Cap

--
~Kevin

[Julian Bond]

Kevin Brown <et...@google.com> Sun, 30 Mar 2008 16:23:00

>This could always just be an object with numerous properties, as in:
>
>presence: {
>  status: "online",
>  statusMessage: "I'm not home right now...",
>  ...other fields...
>}
>Easily maps in the REST API as well.

I'll confess to trying to think of every possible complication. ;)
Perhaps the most significant one is the Twitter-Like Status or IM Mood.
Does this need to be handled separately? Or is just part of presence?
There's something a bit odd here that Orkut and other Google properties
don't have this property apart from a simple one in GTalk.

--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat

Bottled At Source

[Cassie]

1) Alright, so to capture all the comments on this thread we could create a new opensocial.Presence object which has the typical getField() method and a Field enum that can be extended. You would be able to use supportsField to see which things the container supports etc etc. We would also need to add a presence field to the person object which would be a opensocial.Presence object.

-or-

2) We could just use an enum. So the person object would get a presence field of type opensocial.Enum with the enum's key referencing a new opensocial.Enum.Presence field. This would contain the XMPP protocol values and of course can be extended with custom display names.
 

Which one do we want? highly customizable object or simple enum?
Thanks.

- Cassie

[Paul Lindner]

On Tue, Apr 01, 2008 at 01:24:52PM +0200, Cassie wrote:
> 1) Alright, so to capture all the comments on this thread we could create a
> new opensocial.Presence object which has the typical getField() method and a
> Field enum that can be extended. You would be able to use supportsField to
> see which things the container supports etc etc. We would also need to add a
> presence field to the person object which would be a opensocial.Presence
> object.
>
> -or-
>
> 2) We could just use an enum. So the person object would get a presence
> field of type opensocial.Enum with the enum's key referencing a new
> opensocial.Enum.Presence field. This would contain the XMPP protocol values
> and of course can be extended with custom display names.
>
>
> Which one do we want? highly customizable object or simple enum?
> Thanks.

Either proposal meets our needs. #2 seems the simpler option and
corresponds to hi5's current implementation.

> On Mon, Mar 31, 2008 at 9:03 AM, Julian Bond <julia...@voidstar.com>
> wrote:
>
> >
> > Kevin Brown <et...@google.com> Sun, 30 Mar 2008 16:23:00
> > >This could always just be an object with numerous properties, as in:
> > >
> > >presence: {
> > > status: "online",
> > > statusMessage: "I'm not home right now...",
> > > ...other fields...
> > >}
> > >Easily maps in the REST API as well.
> >
> > I'll confess to trying to think of every possible complication. ;)
> > Perhaps the most significant one is the Twitter-Like Status or IM Mood.
> > Does this need to be handled separately? Or is just part of presence?
> > There's something a bit odd here that Orkut and other Google properties
> > don't have this property apart from a simple one in GTalk.
> >
> >
> > >
> >
>

> 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

[Cassie]

Okay, how many votes for this then?

/**
* @static
* @class
* The enum keys used by the presence field.
* <p><b>See also:</b>
* <a href="opensocial.Person.Field.html">
* opensocial.Person.Field.Presence</a>
* </p>
*
* @name opensocial.Enum.Presence
*/
opensocial.Enum.Presence = {
/**
* The entity or resource is off line.
* @member opensocial.Enum.Presence
*/
OFFLINE : 'OFFLINE',
/**
* The entity or resource is on line.
* @member opensocial.Enum.Presence
*/
ONLINE : 'ONLINE',
/**
* The entity or resource is temporarily away.
* @member opensocial.Enum.Presence
*/
AWAY : 'AWAY',
/**
* The entity or resource is actively interested in chatting.
* @member opensocial.Enum.Presence
*/
CHAT : 'CHAT',
/**
* The entity or resource is busy (dnd = "Do Not Disturb").
* @member opensocial.Enum.Presence
*/
DND : 'DND',
/**
* The entity or resource is away for an extended period
* (xa = "eXtended Away").
* @member opensocial.Enum.Presence
*/
XA : 'XA'
};

/**
* Person's current online status. Specified as an Enum with the enum's
* key referencing opensocial.Enum.Presence.
* Not supported by all containers.
*
* @member opensocial.Person.Field
*/
PRESENCE : 'presence',

[Cassie]

Alright, this should be an easy one. Please +1, or -1.
Thanks.
- Cassie

[Zhen Wang]

+1

[Kevin Marks]

+1

[Paul Lindner]

+1

[Lou Moore]

+1

[Marco Ensing]

Considering that not every social network is a chat application, I
would suggest option 1 and leave it up to the container how many
fields he can expose.

I'm confortable with Online - Offline. But the DND, Away, Chat seems
rather IM specific what you might not want to impose on all social
networks.

> > On Wed, Apr 9, 2008 at 10:32 PM, Paul Lindner <lind...@inuus.com> wrote:
> > > On Tue, Apr 01, 2008 at 01:24:52PM +0200, Cassie wrote:
> > >> 1) Alright, so to capture all the comments on this thread we could
> > create a
> > >> new opensocial.Presence object which has the typical getField() method
> > and a
> > >> Field enum that can be extended. You would be able to use supportsField
> > to
> > >> see which things the container supports etc etc. We would also need to
> > add a
> > >> presence field to the person object which would be a opensocial.Presence
> > >> object.
>
> > >> -or-
>
> > >> 2) We could just use an enum. So the person object would get a presence
> > >> field of type opensocial.Enum with the enum's key referencing a new
> > >> opensocial.Enum.Presence field. This would contain the XMPP protocol
> > values
> > >> and of course can be extended with custom display names.
>
> > >> Which one do we want? highly customizable object or simple enum?
> > >> Thanks.
>
> > > Either proposal meets our needs.  #2 seems the simpler option and
> > > corresponds to hi5's current implementation.
>

> > >> On Mon, Mar 31, 2008 at 9:03 AM, Julian Bond <julian_b...@voidstar.com>
> > >> wrote:
>
> > >> > Kevin Brown <e...@google.com> Sun, 30 Mar 2008 16:23:00

> > >> > >This could always just be an object with numerous properties, as in:
>
> > >> > >presence: {
> > >> > >  status: "online",
> > >> > >  statusMessage: "I'm not home right now...",
> > >> > >  ...other fields...
> > >> > >}
> > >> > >Easily maps in the REST API as well.
>
> > >> > I'll confess to trying to think of every possible complication. ;)
> > >> > Perhaps the most significant one is the Twitter-Like Status or IM
> > Mood.
> > >> > Does this need to be handled separately? Or is just part of presence?
> > >> > There's something a bit odd here that Orkut and other Google
> > properties
> > >> > don't have this property apart from a simple one in GTalk.
>
> > >> 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        ||||| | | | |  |  |  |   |   |

> > > lind...@inuus.com- Hide quoted text -
>
> - Show quoted text -

[Kevin Marks]

On Fri, Apr 25, 2008 at 3:03 PM, Marco Ensing <ens...@gmail.com> wrote:

Considering that not every social network is a chat application, I
would suggest option 1 and leave it up to the container how many
fields he can expose.

I'm confortable with Online - Offline. But the DND, Away, Chat seems
rather IM specific what you might not want to impose on all social
networks.

As with any other property, your container can chose whether to support it at all, and which of the enum states it returns; you're not required to support all the enum states.

[Paul]

-1 to anything other than ONLINE or not online.

We currently support ONLINE as a filter and as a field on our friends
list fetches, so I would +1 the online boolean for both, but not a
larger list of enumerations.

~Paul

[Paul Lindner]

How about an extensible enum that only contains ONLINE/OFFLINE in the
base spec?

Other sites could then use opensocial.Environment.supportsField() to
add their own extensions to this enum?

Guess I don't understand your opposition, Myspace could easily only
use ONLINE/OFFLINE and ignore the other enum values. Is it that you
don't want to reimplement for 0.8?

[Cassie]

I agree with Paul Lindner on this one. For many of the person sub objects I don't think many containers will be supporting all of the fields. Take body type or address as examples. They define a large set of possible fields to be easily usable by all containers... they are shooting for a union of fields rather than an intersection so that all containers fit in somewhere.

For the presence enum object the thinking is the same. The containers that do support chat need to be able to agree on the very detailed list of enums.. and if a container chooses not to support the full list all they need to do is return false when supportsField('presenceEnum', 'away') (we'll add the constant to supports field) is called and write some documentation about how the container does choose to use the presence object.

Considering these facts do you think this could possibly work for myspace or do you still foresee some problems?
Thanks for your help!

- Cassie

[Cassie]

+ paul so he can comment

[Graham Spencer]

Paul, can you give more detail about why you don't want enums? So far I am +1 on either the enums as stated or a subset of enums that containers can extend (Paul Lindner's proposal), but I'd like to understand more about why Paul (Walker) doesn't like it.

--g

[Paul Walker]

I was not considering this proposal in terms of enabling chat type features.  Could we consider a separate enum/field for online chat presence as opposed to network online presence? 

 

If not, we’re fine w/ a union if others find values in a more verbose list of values.

 

~Paul

 

From: Cassie [mailto:do...@google.com]
Sent: Tuesday, April 29, 2008 7:55 AM
To: opensocial-an...@googlegroups.com; Paul Walker
Subject: Re: Online PRESENCE Proposal

 

+ paul so he can comment

[Paul Lindner]

On Wed, Apr 30, 2008 at 11:50:08AM -0700, Paul Walker wrote:
> I was not considering this proposal in terms of enabling chat type
> features. Could we consider a separate enum/field for online chat
> presence as opposed to network online presence?

> If not, we're fine w/ a union if others find values in a more verbose
> list of values.

The proposal is for Network Presence, not Chat Presence. I'd like the
extra fields because:

* We want to use more descriptive idle/offline
* I'd like to use the same enum for chat at some point. Aligning
with the fixed status modes from XMPP seems ideal.

--
Paul Lindner ||||| | | | | | | | | |
lin...@inuus.com

[John Hjelmstad]

There's the enum, and there's the Person field name.

So,
A) If we're defining Network Presence, I'd say that irrespective the enum decision we should call it NETWORK_PRESENCE to avoid conflation with a future "Chat" presence.

B) My preference is for the fixed enum, which containers can choose to use or not depending on context.

--John

[Paul Walker]

K, from the developer's perspective I'd prefer to see a separate enum
for chat presence than for site presence, but I'm ok with returning not
implemented for the chat specific value....

So, I will zero out my -1 w/ a +1. :-)

-----Original Message-----
From: opensocial-an...@googlegroups.com
[mailto:opensocial-an...@googlegroups.com] On Behalf Of Paul
Lindner
Sent: Wednesday, April 30, 2008 11:59 AM
To: opensocial-an...@googlegroups.com
Cc: Cassie
Subject: Re: Online PRESENCE Proposal

[Paul Lindner]

Naming changes are fine by me...

On Wed, Apr 30, 2008 at 04:02:39PM -0700, Paul Walker wrote:
>
> K, from the developer's perspective I'd prefer to see a separate enum
> for chat presence than for site presence, but I'm ok with returning not
> implemented for the chat specific value....
>
> So, I will zero out my -1 w/ a +1. :-)
>

[Cassie]

Okay, so it seems like the enum will still be called just "presence", and the field will be called networkPresence, and then everyone is happy.
Fantastic and approved!

Thanks.
- Cassie