[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