[OGo-Discuss] Bug 1852: support creation of xmpp: field types in OGo

Adam Williams discuss@opengroupware.org
Sun, 25 Mar 2007 12:18:04 -0400


On Sun, 2007-03-25 at 11:01 +0200, Helge Hess wrote:
> On Mar 24, 2007, at 18:30, Adam Tauno Williams wrote:
> > http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1852
> >
> > This seems useful, and overdue;  it has come up on the mailing list
> > before although I can't seem to find the thread.  It also seems  
> > related
> > to Bug#1274
> >
> > http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1274
> >
> > Outlook provides an IM address field and this is stored in the
> > im_address field of the person table.  But it doesn't seem to provide
> > any way to specify what kind of IM service is being used;  so I  
> > like the
> > Bug#1852 solution better.
> 
> Hm, yes. As mentioned IMHO an IM field is more like a phone number,  
> though thats not typed further either. The UI would need to check the  
> string contents to decide what to render.
> But I don't mind ;-)
> 
> 
> > Question #1) Is there any kind of policy/philosophy with regard to
> > adding new types of extended attributes?
> In general extattrs are bad because they slow down the system  
> (different relation in the DB, lots of joins, assemble/dissably in  
> the app etc).
> Eg email1 should have been company.email from the beginning (I think  
> it was added later on).

Ah!  I've always wondered about that.

> Now the questions was on "new types". Adding new types of course  
> doesn't hurt, only people using more of them does ;-)
> What I always wondered is whether we are going to drop the  
> 'company_value' and use 'obj_property' like other objects. But I  
> suppose thats not going to happen in the OGo 5.x line given thats it  
> is a larger change.

It would be nice to have just one mechanism for storing custom data. :)

> > Question #2) If the Bug#1852 solution is used perhaps we should  
> > consider
> > created an extended attribute type of each of the *major* IM service
> > types so a corresponding URL can be generated.  XMPP, OSCAR (AIM/ICQ),
> > MSN, SIP, YMSG (Yahoo) and Skype? (ex types 20, 21, 22, 23, 24, and  
> > 25?
> Good question. Can't we just have one IM type which stores the IM  
> service URI. Like: aim:helje5?

Makes sense.

> Of course the component/element which shows the value must parse this  
> for display. And the editor might need to support the user.

Something like: <select box:IM service>[entry: screenname] ?  Put
together and subsequently crack the value at the ":".

> Its a bit more difficult to implement, but sounds like the better  
> option to me.

Right, only the IM URLs can be a bit more complicated.  For instance, as
mentioned earlier, the URL for sending to an AIM account is: <a
href="aim:goim?screenname=notarealuser">...</a>

> 20 would mean: URL which points to a chat identity (in every other  
> way it would be a regular URL field anyways? [do we have a URL  
> type?? ;-)])
> > Can each of these services be referenced via URL?
> Most likely, yes.