[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Stuff I'm working on
From:       "Mauro DePascale" <mauro.depascale () marconi ! com>
Date:       2002-09-10 13:05:01
[Download RAW message or body]


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 <sanders@kde.org>@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
[prev in list] [next in list] [prev in thread] [next in thread]