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

List:       kmail-devel
Subject:    Re: KDE task orientation -> Konqueror-KMail integration / Folder
From:       Don Sanders <sanders () kde ! org>
Date:       2003-10-31 7:22:11
[Download RAW message or body]

Hi,

I finally found the time to answer this sorry for the delay.

On Friday 24 October 2003 19:17, Marc Mutz wrote:
> On Friday 24 October 2003 07:08, Don Sanders wrote:
> <snip>
>
> > I think to avoid confusion, and the need for re-iteration it
> > makes sense to commit this written account of the process to cvs
> > in a POLICY file.
>
> <snip>
>
> I think the main problem we're having here is that different groups
> of KMail developers have different visions for the future of KMail
> as a stand-alone application as well as a part of Kontact.
>
> I think from time to time those visions should be clearly spelled
> out from all sides involved, so that we don't act childish in
> public whenever a developer seems to declare his personal vision
> (in mail or commit) in a way that hides the fact that it's his.
>
> To boot this, I'll start:
>
> I'd like KMail to go into the direction of what it's currently
> strong in already. I think this is security, internationalization,
> filtering, as well as innovative MIME handling (which it lacks
> currently, except for the MIME part tree viewer).
>
> Security here means better integration of the Aegypten stuff to the
> point that S/MIME and OpenPGP/Aegypten and KPGP combine the best
> features of them to form a multi-protocol client that is even more
> user-friendly as the KPGP-based code is now. It's clear that the
> boundaries between S/MIME and OpenPGP are blurring by the day. I
> hope we can create innovative UIs that expressedly blur that
> boundary for the user, too.

More user-friendly would definitely be good.

> Internationalization here means that we leverage the advantage of a
> Unicode-centric Free Software project and be among the first to
> implement whatever comes out of IMAA. Another open problem that
> no-one (!) has yet solved in the whole industry of messaging
> systems is virtuous and intuitive handling of multi-lingual (or
> better: multi-script) message composing. This is an area where we
> need to innovate and actually do research; an area where we can't
> copy from Outlook or even the master of the art - Mulberry - simply
> because everyone sucks in this area :-)

I think this is important. I suspect weak internationalization will 
tempt free software developers in countries like Japan and China to 
create their own desktop environment and messaging apps rather than 
contribute to KDE.

> Filtering here means native Sieve, of course. The area of Sieve GUI
> editors is currently claimed by web-based approaches as well as the
> primitive Mulberry Sieve editor. This is also an immensely
> interesting area of UI design: How do you implement an UI that
> allows the full power of the Sieve language to be expressed in a
> user-friendly form? I don't know. Yet.

Again I think this is an important area. Working on client side imap 
filtering has taught me to better appreciate the benefits of sieve.

> With innovative MIME handling I mean composing complex MIME mails
> that help implement the Security and Internationalization points
> above. E.g. mp/alternative that differ in Content-Language only. Or
> mp/signed whose second part is a mp/alternative, allowing a message
> to be signed in both S/MIME and PGP/MIME format. I'd really like to
> explore how the support for this construction is in other mailers.
> Another area is rich-text editing with automatic choice of format
> (plain, f=f, enriched, html, alternative).

Ok.

> Apart from a clear layering (which is a technical point),

Technically I desire the KMail architecture to allow new features to 
be implemented easily without cluttering the KMail code or UI.

Perhaps this can be achieved by unifying the message classes into a 
single class, creating ids and implementing ref counting for all 
persistant objects such as filters, filter actions, messages, 
folders, folder managers, identities, etc, and creating private 
(kdepim only) interfaces for these objects. 

Then perhaps code like KMCommands and KMFilterActions could be 
implemented as plugins that use the private KMail dcop interfaces, 
(it might also be nice to move code out of KMMessage into KMCommands, 
and unify KMCommands and KMFilterActions in some way). 

Perhaps these plugins could be implemented as KParts. That way plugins 
could create new menu items, including new context menu items for the 
reader window and message list widgets, in addition to new kmcommands 
and filter actions. Perhaps even the reader window, folder tree and 
message list widgets themselves could eventually be turned into 
KParts that talk to the rest of KMail via the private dcop interface.

Not all plugin KParts would have to loaded by default, sets could be 
disabled/enabled in the configuration dialog.

The ideas in the last paragraph are in the formative stage in my mind, 
I doubt I'll have time to work on them anytime soon, and really I'd 
prefer discussing design issues over a drink rather than on a 
(comparatively low bandwidth) mailing list.

> I think 
> that's where I see the strengths of KMail and potentials for
> enhancement with the aim to be different (read: on top of the
> competition instead of copying behind it).

I realize that free software in general has been criticized for 
'following tail lights', but I've seen many free software projects 
that have one or two cool features but that in general can't match 
the features of competing (free and proprietrary) projects and fail 
to attract a substantial user base for that reason.

I think to move ahead of the competition it's important to have 
distinguishing features. However I believe it's just as important to 
avoid falling behind by identifying and eliminating weaknesses, such 
as missing features that are drawing users to competing projects. 
Hopefully this intention to identify and eliminate weaknesses can be 
seen as complementary to your own goals.

> I don't feel the need for KMail to become a document management
> system, or a frontend for one. I think making the reader a part and
> the composer a part or even a separate application makes it
> possible to implement all sorts of interesting custom or standard
> workflow and document management systems, but I believe that's out
> of the scope of KMail as an app, and that's probably what Ingo
> tried to say.
>
> I see the need for KMail to implement more of the IMAP standard
> (mostly ACLs, SEARCH), but unless it starts itching me, I will not
> scratch that area. We have enough clever people working on that
> already :-)

For myself to briefly give some specifics I'm interested in 
implementing, html editing, leave mail on server for n days, async 
filtering, client side imap filtering, full text indexing, and 
multipart related support. Generally I'm interested in implementing 
features that are in high demand as shown by 
http://kontact.org/votes.

Perhaps it would be beneficial to discuss not just a single roadmap, 
but discuss more generally the process of creating roadmaps, or the 
process of deciding what is ok to work on in general.

It is my intention to negotiate terms for implementing features with 
the decision making group, on a case by case basis if necessary. Let 
me explain what I mean by terms. 

As an analog in meatspace a company might want to open a gold mine. 
The company hopes to profit by providing society with valueable gold, 
at the cost of using scarce resources and the social cost of 
producing pollution. These negative side effects of production are a 
problem that requires a political solution, the company must 
negotiate operating terms with the representatives of the community, 
the government.

Likewise I hope to profit by implementing features, likewise there is 
the potential for social costs to arise, such as bugs causing the cvs 
version of kmail to crash for users etc. Thus I was forced to 
recognize the need for a political group that I can negotiate terms 
with so that I may conduct my business, and I see the KMail decision 
making group as being capable of fulfilling that need. I also needed 
a concrete decision making protocol so that I can think about things 
from a rational political science / game theory perspective.

The kind of terms I'm thinking of are don't commit code with known 
bugs, document new features, minimize gui clutter, try to fix code in 
other people's code as well as my own, describing my intentions to 
assist in strategic planning, basically be a good citizen of the 
KMail developer community by fulfilling my civic duties.

As far as details go as to how I expect to profit by implementing 
features. Basically I require a large number of organizations and 
individuals to choose KMail because it profits them to do so, because 
it's the best choice for them. Once this is achieved I believe those 
organizations and individuals will seek improvements in KMail to make 
them more profitable and I hope to negotiate terms with them to 
prioritize and implement those improvements.

For Kontact it has been agreed to launch a pilot program and website 
to explore this idea. Beyond that I would prefer not to discuss 
details on the public lists but i'm happy to do so in private.

As far as not following tail lights go this is what I hope can be a 
killer feature. Not a technical innovation but a 
socio-political-economic one, that allows contributors, including 
developers to improve free software in a profitable and sustainable 
way.

Don.
_______________________________________________
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]