Forum OpenACS Development: Adding online presence

Posted by Lars Pind on 05/12/04 02:38 PM

It looks like it's pretty easy to add icons that show if a user is online on the major IM services, if only we collect users' messenger account names.

Y!M: http://messenger.yahoo.com/messenger/help/online.html

AIM: http://www.cconvergence.com/shared/printableArticle.jhtml?articleID=8701355

I can't find the same for MSN/Windows messenger or Jabber.

Why don't we just go ahead and add the relevant columns to the users table, and start adding in the links?

Better yet, extend ad_present_user to handle these things.

/Lars

2: Re: Adding online presence (response to 1)

Posted by Malte Sussdorff on 05/12/04 03:09 PM

This information and related things are already collected if someone installed the jabber package :). If it should be collected someplace else, the better. Once Jabber is installed you can get the MSN and Jabber as well as ICQ information.

Drawback: Currently only Oracle, not adapted to 5.1/2.1 (4.6/1.0 works with it though).

3: Re: Adding online presence (response to 1)

Posted by Ben Koot on 05/12/04 05:49 PM

Lars,

Does this unofficial info on MSN help? http://www.hypothetic.org/docs/msn/notification/presence.php
http://www.hypothetic.org/docs/msn/general/names.php

Cheers
Ben

4: Re: Adding online presence (response to 1)

Posted by Nis Jørgensen on 05/13/04 03:55 PM

Without having looked at what the jabber package does, may I strongly suggest that we do not be add one field to the users table for each instant messaging service, but rather as a separate table with a one-to-many relationship to users? Probably we will need a table for listing the available services as well.

This not only to avoid having to change the data model for every new service popping up, but also to allow for multiple ids of the same type for teh same user.

5: Re: Adding online presence (response to 4)

Posted by Jeff Davis on 05/13/04 04:24 PM

I agree with Nis here, and would add that we should also make a provision for allowing users to restrict who can see their information (which I think would argue for making a "contact" object_type which could be permissioned).

6: Re: Adding online presence (response to 5)

Posted by Bjoern Kiesbye on 05/17/04 03:54 AM

The jabber package uses the object type jb_screen, a relation to object type party , could be used to handel permissions to read IM informations of a user.

We allready have a table to store all available IM services, acs-admins are able to de/activate singel IM Services.

The jabber package is not able to handel more then one screen for a Service and User.
I'm not sure if this is neccessary , I think it may be more usefull to let a user have more than one Identity under wich he can handel a set of screens (one for each IM Service).
This way the contacts of a user get better organized, all conntacts he adds to his 'Work' identity will be displayed under this Identity don't matter from wich IM System they are. If he has a second screen (for privat use) in any IM Service, he can create a new 'Privat' Identity, and use the screen with this Identity.

7: Re: Adding online presence (response to 1)

Posted by Lars Pind on 05/20/04 03:30 PM

... and there goes yet another clearly useful feature, which doesn't get into the software, because we keep insisting on the complete, generalized solution. Or is that just me ending up feeling this way?

8: Re: Adding online presence (response to 1)

Posted by Dave Bauer on 05/20/04 03:34 PM

Lars,

I don't think adding a bunch of columns to users is a good idea. I don't think we need a complex solution either. We know that users will often have more than one IM. This looks like a two table solution would work. A list of IM types and a table of IM nicknames mapped to user_id.

This is extendable, but its not over designed, I think.

9: Re: Adding online presence (response to 1)

Posted by Dave Bauer on 05/20/04 03:35 PM

Hmm, Jeff's right too :) We might want to control visibility, but still, select acs_object_type__create_type isn't so had to type. It might take a few more minutes, but its not impossibly complex.