[Kde-pim] KDE/kdepim/runtime

Casey Link casey at kdab.com
Tue Jun 1 13:41:42 BST 2010


On Tuesday, June 01, 2010 02:21:09 am Kevin Ottens wrote:
> What do you mean by "break" here? Keep in mind that there's probably some
> users with this resource configured already (as the first release with the
> imap resource was the 4.4 one). We have to make sure we're not alienating
> those.
Hm, I did a huge slew of imap/pop3/smtp config changes in march/april, and 
Thomas  said it wasn't necessary to update the configs then.. but I can create 
an update script if necessary.

> If really the main motive is the javascript side of things, why not bind
> said enums to the javascript interpreter instead of using strings or magic
> values?

Because, the way the wizard framework works now, it  uses the same encryption 
values (see accountwizard/transport.h) for EVERY wizard (imap, pop3, any other 
new one, etc), so binding one enum will require mapping to another later. For 
example, mapping from MailTransport::Transport::EnumAuthenticationType to 
KIMAP:: EncryptionMode.

I'm all for changing it for the better, however (1) I didn't think binding 
enums to javascript was possible considering Volker went through the trouble 
to setup stringToEncryption() and stringToAuthType() functions. If it is 
possible, then lets do it. 

Second, it would be great if every resource could use the same auth/encryption 
enums, but that may not make sense. 

Third, if we *have* to reference enums by their integer value.. we lose type 
safety (the main benefit of enums), so I think using strings is safer. Not to 
mention the default ordering/values of enums could change depending on the 
compiler, so what was 1 might now be 2, etc. Unlikely, sure.

Casey
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/



More information about the kde-pim mailing list