[GSoC 2012] Planned API changes - RFC

[Ethan Blanton]

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.

Ethan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20120703/a47ae318/attachment.sig>