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

[Adam Williams]

> > > 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 ;-)
> good ;)
> > Now the questions was on "new types". Adding new types of course  
> > doesn't hurt, only people using more of them does ;-)
> I started with adding an xmpp: url link, but now I think it would be better 
> to add sth. more generic than an xmpp link, just add,

I think a type specific to an IM entry is best if we go the extended
attribute route,  as it makes it easier for other UIs to understand as
well.  And there are few enough IM services that even if URL-kind
support is hard coded it doesn't strike me as a bih deal.

There are UIs than the web interface? :)
http://docs.opengroupware.org/Members/whitemice/consonance/ConsonanceScreenshot20070322/image_view

And it should be assumed there will be more in the future.

If one sees an extended attribute of type 20 then one knows one is
looking at a IM address,  vs.  if there is magic URL mangling it is
harder.    Cracking a value like "aim:fred" is simple enough.

 
> > > 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?? ;-)])
>  so I changed the patch to be able to define arbitrary link types via 
> OGoExtendedUrlAttributesMap Default, for example:
>         OGoExtendedUrlAttributesMap = (
>             {
>                 type = 3;
>                 urlpattern = "mailto:%@";
>             },
>             {
>                 type = 4;
>                 urlpattern = "%@";
>             },
>             {
>                 type = 20;
>                 urlpattern = "xmpp:%@";
>             },
>             {
>                 type = 21;
>                 urlpattern = "fish://%@";
>             },
>             {
>                 type = 22;
>                 urlpattern = "imaps://%@";
>             }
>         );

Mmm,  I really don't think this is necessary,  although I understand the
intent.  Problem is that URLs can actually get more tricky than one ever
initially suspects.  IMAPS is a good example.

My vote, at this point, is to create a type "20" that is
"{service}:{screenname}" and have the object viewer generate the
appropriate link type based on service.

> SkyPublicExtendedPersonAttributes = (
>             {
>                 key = jabberid;
>                 target = "_self";
>                 type = 20;
>             },
> the ordinary url type is of type 4 (or has an attribute href) and email is 
> type 3, 
> I changed SkyObjectField.m to consider everything above 19 as a special link 
> type, defined in OGoExtendedUrlAttributesMap, together with a definition of 
> email and url type.
> So this is not yet working for objects using LSWObjectViewer.m, should I add
> the same there too? I am not sure whether it is really needed there.