[Tickets #10093] Re: Cannot create folder name with ampersand

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/10093
------------------------------------------------------------------------------
  Ticket             | 10093
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Cannot create folder name with ampersand
  Queue              | IMP
  Version            | Git master
  Type               | Bug
  State              | Assigned
  Priority           | 3. High
  Milestone          | 6
  Patch              |
  Owners             | Michael Slusarz
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2011-06-07 06:11) wrote:

> 1. Why can't IMP 5.1 require a newer version of a specific package?  
> Isn't that part of the intent of the separate framework packages?

This was my understanding/belief also.  A minor version bump is  
intended to indicate that the basic framework is the same (i.e. no  
major data/configuration changes), but that there may be some  
substantial changes to the underlying system to fix limitations in the  
previous version.

> 2. Is the change to Horde_Imap_Client one that will break IMP 5.0,  
> or is it just that this bug won't be fixed without it?

Right now, Horde_Imap_Client accepts either UTF-8 or UTF7-IMAP strings  
for all mailbox parameters.  This needs to be changed to  
Horde_Imap_Client accepting UTF-8 strings only (since it can not be  
100% reliably auto-detected).

I am positive that IMP passes both types of strings to H_I_C methods.   
So this needs to be changed to UTF-8 only.  But this change in IMP is  
worthless if there is not a corresponding change in H_I_C - since we  
need to be calling a version of H_I_C that does not do any  
auto-conversion.

There are other things that need to be fixed in H_I_C (allowing  
multiple mailboxes to specified to search(); returning the list of  
UIDs that were altered in store() instead of a boolean) that should be  
done sooner rather than later.

> 3. No matter how long we took on the release, we would have found  
> something like this.

That is probably true - this is a bit broad of a statement on my part.  
  But locking ourselves into an API, without the benefit of  
broad-based, thorough testing, is a terrible thing.  This was the #1  
failure of Horde 3 - we should not be supporting broken APIs for  
(potentially) years simply because that happen to be the state of  
things the second version x.0 came out.