Re: Bug 1852: support creation of xmpp: field types in OGo

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).

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.


> 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?

Of course the component/element which shows the value must parse this  
for display. And the editor might need to support the user.
Its a bit more difficult to implement, but sounds like the better  
option to me.

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.

Greets,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/


-- 
OpenGroupware.org Discussion [email protected]
http://mail.opengroupware.org/mailman/listinfo/discuss