New possible design iterations

[Philip Van Hoof <spam pvanhoof be>]

Hi there mailing list and SoC student planning to do a project that
might use tinymail. For people who are planning to join the development
of tinymail. Read this carefully:

You'll note that it has been written with a no-bullshit idea in mind.
Most expert software developers like that. Do not take things personal.


Introduction and about all this
-------------------------------

	The next development iterations for tinymail will look like this (x).
The proposals, new proposals and design decisions are open for
suggestions and discussion during so called "standup meetings". So if
one or more people are interested in discussing this with me, I propose
you install Ekiga, contact me in private and I'll set up a Asterisk room
where we can have a VoIP group meeting (I have this infrastructure
ready).

	Each point will launch a new development iteration (design, implement,
test and document). If people are interested in joining a specific such
iteration, they can express their willingness on this mailing list. Each
developer will *have* to attent and help-perform EACH part of such an
iteration (design, implement, test and document). Else the same
developer can better simply decide not to join the iteration. 

Or to make this sentence more clear: he or she is not welcome as a
developer: It wouldn't work in a Agile development model and team.

I know that sounds harsh but it would be a sign of no leadership if I
wouldn't make that decision. I know some people are interested in
helping. Those people should take note that any team-driven development
will happen as Agile as possible. Therefore must each team-member
understand how one iteration happens.

	I'm not yet sure if I'd like to let the iterations happen in parallel.
I'd prefer if the whole team would focus on one iteration. But perhaps
are some iterations be combined. This is typically something that should
be discussed during such a "VoIP standup meeting".

	I'm also very interested in people who have had experience with Agile
development methods like Extreme Programming in the free software
domain. I hope VoIP technology (like Asterisk and Ekiga) can for example
be used to replace the standup meetings.

	Each finished iteration will cause a release. Such a release can be a
snapshot or a real release. That, for now, depends on my decision. If
nobody joins, it means that I'll develop these iterations myself. Which
means that you can predict releases by following my personal blog and/or
this mailing list.

	Leadership switches like a release maintainer and/or a person who'll
take leadership responsibilities are possible and to be discussed during
a VoIP meeting. Make sure you have a good reason, a lot experience with
Agile development models and show (me) that you are, indeed, capable of
performing the leadership-tasks you'd like to perform. Tinymail will not
use na�e democracy. Democracy stinks for software development
projects: it needs hard and quick decisions like a dictator can take
during wartime. This doesn't mean that you can't discuss things during
"VoIP standup meetings". And you can always fork, as tinymail is LGPL,
and prove that asshole dictator wrong.


The possible next iterations (x)
--------------------------------

Note that these are discussable (read above) during a standup meeting
(but we'll use VoIP or for very short discussions IRC or Jabber). Not
E-mail nor this mailing list. I don't see E-mail as a good platform to
do modern software development discussions in a Agile environment. E-
mail is a good platform for meeting-reports, not for discussions.


o. Fix the stream issues. Fix the memory issues caused by aggressively
freeing memory (there's a few memory issues with ghost proxy instances
when swapping the model of the header tree view).

o. Create a Online-Observable (interface and singleton). Make
TnyCamelSession an observer of the Online-Observable. Make it possible
to implement the interface on a specific device. For example on a WinCE
device, some ActiveSync techniques could be used. On a Nokia device
other specific techniques could be used.

o. Refactor the account-store to a normal type (not a singleton). Make
it possible to have multiple such account-stores (each having one
TnyCamelSession instance, so the TnyCamelSession instance is also no
longer a singleton in that case).

o. Refactor the getting of headers to a strategy pattern for the folder
type. Implement an asynchrone such strategy and a synchrone such
strategy. The asynchrone would inherit (or reuse) the synchrone one.

o. Make the getting of messages asynchrone. Possibly using the same
strategy idea.

o. Implement more and more useful unit tests.

o. Rethink the subscribe and- unsubscribe folders infrastructure.

o. Refactor the transport account to a strategy of a store account type
rather than a subclass of an abstract account type (how its now).
Implement a dummy store account for transport accounts that don't have a
store (less likely, but some people use this).

o. Make it possible to switch the transport account quickly (setting the
strategy property): Connection changes (wifi, activesync, usb connector,
etcetera) can cause changes in the account being used for transport.
Hence make an observer for the "Online-Observable" that uses a
configuration and decides on "connection-situation change" which
accounts get which transport strategies.



-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be