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

[Adam Williams]

> >                 type = 22;
> >                 urlpattern = "imaps://%@";
> >             }
> >         );
> > SkyPublicExtendedPersonAttributes = (
> >             {
> >                 key = jabberid;
> >                 target = "_self";
> >                 type = 20;
> >             },
> A new type only makes sense when the semantic information would be  
> useful. In all other cases its the task of the UI to process URLs in  
> a better way.
> Wrt to URL patterns, those should be but in the attribute  
> configuration! Eg:
>              {
>                  key        = jabberid;
>                  target     = "_self";
>                  type       = 20;
> 		urlpattern = "xmpp:%@";
>              },
> and
>              {
>                  key        = aimid;
>                  target     = "_self";
>                  type       = 20;
> 		urlpattern = "aim:%@";
>              },
> '20' would just mean its an IM address (having an own type for IM  
> might make sense, though I'm not entirely convinced of that either  
> since a generic URL UI can easily detect that a URL is a chat one).
> Though I also dislike the urlpattern in this case. The database  
> should store the full URL, not just the value the user entered. 

"database should store the full URL" makes sense,  but, again, what
about cases where the URL looks like: aim:goim?screenname=notarealuser  
Here the UI would ave to see the "aim:" and take out all the text after
the "=".

> Maybe  
> 'defaultUrlScheme' might make sense (the editor would check whether  
> the value entered by the user has a scheme and if not, would add the  
> default scheme).
> Thinking about it, for the specific case of IM addresses we should  
> really use the Outlook field in the way Microsoft uses it. Its sounds  
> kinda stupid to reinvent the wheel here (how long before people ask  
> about having IM addresses in Outlook/Evolution ...)

Bug#1274

> Hm, all that doesn't look very appealing to me. The patches are not  
> very dangerous and are great fast hacks, but IMHO the issue is not  
> thought out well enough (and I won't have the time to do it right now).
> So feel free to apply them, but I reserve the right to drop support  
> for that in future versions of OGo ;-)