From kmail-devel Tue Sep 10 13:05:01 2002 From: "Mauro DePascale" Date: Tue, 10 Sep 2002 13:05:01 +0000 To: kmail-devel Subject: Re: Stuff I'm working on X-MARC-Message: https://marc.info/?l=kmail-devel&m=103166322731559 Hi, once upon a time, Don, wrote: >On Tuesday 10 September 2002 20:49, Mauro DePascale wrote: > >> Having a more cleaner and neutral interface will help a lot. >> >> I'd like to see also something about centralized and shareable >> account management and a common API/Protocl to communicate with >> trasports' KioSlaves (about the last point: actually KioSlaves just >> share the interface, but each one uses its proper way to >> communicate with the KMail engine). >> >> Perhaps using XML/ASN.1 there can be of help. . . >Please explain more. BTW I can't promise these changes will make it >into the kdenetwork/kmail branch. Well, I don't expect to see them too fast, just an idea not completely focused yet. Anyway, it's not easy to explain for me but I'll give it a try: at the moment KioSlaves and kmacctxxxxx modules communicate using a proprietary protocol, this is a problem for all the cases where re-using the KioSlaves can be profiteable. It would be very useful to define a common communication protocol for all the trasport KioSlaves in order to be able to use them in a transparent way without need to know details about the various protocols on the apps side. At the moment the KioSlave interface is good for raw data (basically to manage block devices). I think it can be greatly improved extending the class with a documents/memos oriented data model. Now, how to represent/implement in a flexible and efficient way such model? A model to be shared among POP/IMAP and other transports, easy to be understood and flexible enough to be ready for future expansion? Perhaps XML can be the answer. We can try to define a schema to represent generic messages (there are many standards and RFCs about it) and use it. If XML shows up to be inefficient (too much bandwidth) we'll have the option to use XML just for modeling and ASN.1 for streaming resulting in a great efficiency speed up. Again, this is just an idea. . .let's me know what you think about it. M. PS Don, >I feel like someone I love has died. But it's not a person that's died it's an idea ideas or dreams can't be killed. Just idealists and dreamers die. You're not alone 'til you really decide to be. Don Sanders @mail.kde.org on 10/09/2002 13.22.22 Please respond to kmail@mail.kde.org Sent by: kmail-admin@mail.kde.org To: kmail@mail.kde.org cc: Subject: Re: Stuff I'm working on Hi, On Tuesday 10 September 2002 20:49, Mauro DePascale wrote: > Hey! > > Sounds as a very big bunch of interesting stuff!!! Thanks. > I'm very interested in the KAddressbook/KMail/KOrganizer framework > because it will be closer to the Notes approach. > I'm also very interested into the KMFolder interface rework: those > protocol == "imap" checks prevent me to add folders support to the > Domino code. Actually Zack has already fixed this and just asked me to check his patch. I told him it was fine and that he should commit. > Having a more cleaner and neutral interface will help a lot. > > I'd like to see also something about centralized and shareable > account management and a common API/Protocl to communicate with > trasports' KioSlaves (about the last point: actually KioSlaves just > share the interface, but each one uses its proper way to > communicate with the KMail engine). > > Perhaps using XML/ASN.1 there can be of help. . . Please explain more. BTW I can't promise these changes will make it into the kdenetwork/kmail branch. But I would just like to work on implementing these features quickly. If something isn't good enough then it can be reverted later, but everybody please leave that to me as I'm maintaining the branch. If I can't come to an agreement with the maintainer then alternatively I can fork. BTW I like the use of the term 'the maintainer' as it nicely sidesteps the issue that I believe I am the legitimate maintainer of KMail. One other note Aaron J. Seigo, since I opened the branch has kindly volunteered to become the GUI maintainer of the branch. So he has complete creative control over all aspects of the GUI and any GUI changes should be cleared with him. Also Zack Rusin has agreed to help me with my architectual improvements and to make some of his own. Which seems to be working well as he just fixed what you complained about. Don. _______________________________________________ KMail Developers mailing list kmail@mail.kde.org http://mail.kde.org/mailman/listinfo/kmail _______________________________________________ KMail Developers mailing list kmail@mail.kde.org http://mail.kde.org/mailman/listinfo/kmail