[GSoC 2012] Planned API changes - RFC
elb at pidgin.im
Tue Jul 3 17:19:17 EDT 2012
Tomasz Wasilczyk spake unto us the following wisdom:
> >> 1) trimming whitespaces from usernames
> > I don't think trimming whitespace is generally a good thing globally,
> > it should probably be on a per-prpl basis, in case whitespace is
> > important to a prpl
> Good point. What about OPT_PROTO_TRIM_USERNAME option? In that case, I
> think it should be handled at libpurple side.
I think the OPT_PROTO_STORE_NORMALIZED option (suggested on bullet 2)
is a good solution for this. I might even be convinced that we should
just store normalized outright. Some protocols (such as AIM)
distinguish between the "display" formatting of a username and the
normalized formatting, but I think we get the display formatting on
signin in at least the AIM case. Mark, can you comment?
Does anyone know of a reason why we shouldn't transition to
normalized usernames in the saved blist?
If there is a reason why we shouldn't, I think we want to turn this
around: why does GG need it, specifically? The bug in #11733 looks
like something a prpl can easily solve for itself, by simply
normalizing incoming usernames before adding them. Also 2) below...
> >> 2) username validation
> > Does username normalisation count as validation?
> At this point - no. Invalid usernames should not be allowed to type in
> dialogs like account setup.
> But we can use normalize function - there is only need to specify,
> that if it returns NULL, that mean username is totally invalid. For
> example, in number-based usernames, normalization for "[space]1234"
> will return "1234", but for "1234x" will it be NULL. That also have to
> be handled in UI.
This seems logical, and almost free, to me.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 482 bytes
Desc: Digital signature
More information about the Devel