Version: 0.99(devel) (using KDE KDE 3.2.1) OS: Linux network transports should use KIO so they can use user settings, support encryption, proxy, non-standard ports, etc
If this is refering to the elog and email stuff, this is high priority.
I believe there is email code in the Kst core which needs to be fixed too.
Does anyone know of a good source of documentation for the kio_slaves, using rather than writing? Also, a search on the smtp kio_slave indicates numerous issues with this kio_slave. Does anyone know if these have been fully or largely resolved?
On Monday 03 January 2005 16:36, Andrew Walker wrote: > ------- Does anyone know of a good source of documentation for the > kio_slaves, using rather than writing? Also, a search on the smtp kio_slave > indicates numerous issues with this kio_slave. Does anyone know if these > have been fully or largely resolved? The smtp slave works perfectly fine and far better than what we have in Kst. As for documentation, for the SMTP slave, you setup the parameters and query and do KIO::put(). See KMSendSMTP in kdepim/kmail/kmsender.cpp for an example. Basically all slaves work like this, and the classes are all documented in the KDE library documentation.
The email configuration settings may be applied to more than just event notifications. Do we want to configure these settings from a new tab of the Kst Settings dialog?
On Tuesday 04 January 2005 18:14, Andrew Walker wrote: > ------- The email configuration settings may be applied to more than just > event notifications. Do we want to configure these settings from a new tab > of the Kst Settings dialog? _______________________________________________ That sounds like the best idea to me. It can pull the defaults from KControl (there is an email setting there). That's the way KMail does it.
CVS commit by arwalker: CCMAIL: 88088@bugs.kde.org Seems to be working okay, but not tested with anything but the simplest SMTP server. M +202 -128 emailthread.cpp 1.6 M +56 -17 emailthread.h 1.3 M +101 -107 eventmonitor.ui 1.26 M +1 -5 ksteventmonitor_i.cpp 1.27 M +4 -11 ksteventmonitorentry.cpp 1.28 M +1 -6 ksteventmonitorentry.h 1.18 M +4 -2 kstsettings.cpp 1.13
CVS commit by arwalker: Remove threading from email notifcation. CCMAIL: 88088@bugs.kde.org M +14 -40 emailthread.cpp 1.7 M +6 -27 emailthread.h 1.4 M +0 -8 eventmonitor.ui 1.27 M +2 -2 ksteventmonitorentry.cpp 1.29
The ELOG server does not support any enryption, login, etc so will not benefit from using the kio_slaves. Unless I hear of anywhere else where the kio_slaves may be of use I will close this bug.
Email notifications from the event monitoring system now use the smtp kio_slave.
A few of the many reasons why it is needed for ELOG HTTP: 1) HTTP Proxy 2) SOCKs proxy 3) Encryption (which indeed can be used in many setups with ELOG, both proxy and non-proxy) 4) Much more reliable HTTP implementation 5) Security 6) Any future changes in ELOG to use cookies, authentication, etc. All of the network protocol implementations in Kst need to use KIO. There are just too many issues, and the overall philosophy is to make Kst fully KIO enabled over time, in all areas.
CVS commit by arwalker: Use KIO for the http connections to ELOG. CCMAIL: 88088-done@bugs.kde.org A elogbasicthreadsubmit.cpp 1.1 [GPL (v2+)] A elogbasicthreadsubmit.h 1.1 [GPL (v2+)] M +1 -1 Makefile.am 1.10 M +7 -6 elog.cpp 1.19 M +1 -1 elog.h 1.5 M +14 -15 elogconfiguration_i.cpp 1.7 M +15 -271 elogeventthreadsubmit.cpp 1.6 M +3 -23 elogeventthreadsubmit.h 1.4 M +27 -98 elogthread.cpp 1.11 M +13 -12 elogthread.h 1.7 M +85 -105 elogthreadattrs.cpp 1.8 M +10 -3 elogthreadattrs.h 1.2 M +161 -201 elogthreadsubmit.cpp 1.15 M +36 -19 elogthreadsubmit.h 1.6