Home
The Toolkit for Online Communities
17478 Community Members, 0 members online, 1956 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : Adding online presence

Forum OpenACS Development: Adding online presence

Icon of envelope Request notifications

Collapse
Posted by Lars Pind on
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

Collapse
2: Re: Adding online presence (response to 1)
Posted by Malte Sussdorff on
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).

Collapse
3: Re: Adding online presence (response to 1)
Posted by Ben Koot on
Collapse
4: Re: Adding online presence (response to 1)
Posted by Nis Jørgensen on
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.

Collapse
5: Re: Adding online presence (response to 4)
Posted by Jeff Davis on
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).
Collapse
6: Re: Adding online presence (response to 5)
Posted by Bjoern Kiesbye on
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.

Collapse
7: Re: Adding online presence (response to 1)
Posted by Lars Pind on
... 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?
Collapse
8: Re: Adding online presence (response to 1)
Posted by Dave Bauer on
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.

Collapse
9: Re: Adding online presence (response to 1)
Posted by Dave Bauer on
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.