Re: New todo summary

[Philip Van Hoof <spam pvanhoof be>]

On Mon, 2006-12-11 at 15:28 +0100, Philip Van Hoof wrote:
> After this summary, I promise a new huge requirements/todo list ;-). So
> don't be afraid, it would not mean the end of the project.
> 
> 
> - Getting message/alternative in rfc822 messages to be displayed
>   correctly (normal)
> - Rewrite of tny-camel-mime-part.c (urgent)

These two are actually one item, as the latter will solve the former and
visa versa.

> - Content-type in mmap (difficult to get this right and to debug it)
>   (low priority)

This would reduce 7% memory usage. There's a patch available that
attempted this. The patch, however, introduces a segmentation error when
downloading new message-info from an IMAP service.

Making me believe that at least one occurrence is not yet fully covered
and/or replaced with the mmap-style of storing it in memory (they need
special care when freeing them, and only in case they are at that moment
not in mmap. Things like that).

> - Creating a solution for the TnyGetPassFunc and TnyForgetPassFunc when
>   they are called by another thread (implementers will often introduce
>   gtk components like password dialogs in the implementations, should be
>   simply document using gdk_threads_enter() or should be solve this
>   differently?) (urgent)

The problem here is that the "alert", "get_pass" and "forget_pass"
methods, which are to be implemented by te application developer or in
the platform specific library, can have user interface code.

As everybody knows can't gtk+ user interface code be mixed with multi
threaded things. You need to gdk_threads_enter/leave that code in order
to gain a lock on the ui in your thread.

At this moment there's a mix usage between in-main thread and in-worker
thread. 

It would be better to normalise this to always-in-main thread if there
is a mainloop (and else in the worker-thread). Which is not by itself an
easy task. Especially given that in the library itself you can't expect
a mainloop to be 'per definition' available (yet a mainloop might very
well be and is likely to be available, in which case it should also be
used).

Maybe the entire concept is wrong? Maybe we should use our brain a
little bit more before trying to hack this right?

> - Error passing (GError style) when connecting with a store and
>   transport service (urgent)

Again, the problem illustrated above adds to the complexity of making
this possible.

> - Implementing a TnyAvahiSendQueue classifier (low priority)

It would be a nice example implementation for TnySendQueue.

> - Testing TnyCamelSendQueue (urgent)

Testing testing testing. It seems to work. It needs more testing.

> - TnyAsyncFolder/TnyFolder refactoring (not sure yet) (low priority)

I'm getting more and more in favour of this. Why? Simple!

Because that would allow an application developer to wrap his own
implementation of asynchronousy around normal implementations.

Right now he would HAVE to inherit and override methods. Then, he would
have to implement an interface.

I'm more in favour of letting people implement. Overriding is something
somebody should only have to do if he also typically needs to reuse the
existing old method on the super instance.

And even then, I'm more pro decorator and decorating rather than
inheritance. Inheritance is often the typical wrong solution and only
often picked by somebody "because his teacher told him about it" (but
didn't about the other possibilities).

The interface idea would allow inheritance w. overriding, decorating and
fully reimplementing. The current design only allows inheritance w.
overriding.

Flexibility! Be adaptive!

But what do other people think? I'm keeping it a low priority for now.

I will consider changing this API before 1.0. For most people this is
only going to mean doing a little search/replace on at most two or three
API calls in their (Modest) code ;-). Right? :)

ps. I know I'm the evil 666 API changer. But then again, I warned people
about this didn't I? =]. I want it to be perfect. Not almost perfect.

No compromises on design unless I really really really really have to.

But let us discuss it if people want to discuss it. I'll try to be open
minded on opinions if they are based on technical merits (somebody
having to do a little search and replace is not a good reason not to do
something).

> - Testing tny_folder_get_msg_async (urgent)

Simple, test the functionality. Check locking. Stuff like that. I have a
testing IMAP account on imap.tinymail.org. Everybody is allowed to use
it for that purpose. And yes, it's okay if you by accident or caused by
a bug nuke the account. I'll recover it, so don't be afraid.

> - The retrieval status of a message in the flags of a TnyHeader (low
>   priority that might change)

Because partial message retrieval is not implemented yet, I don't yet
see the point of this. It's a requested feature, so at some point this
information will be available in the header instances.

> - Java bindings (low priority)

I talked a little bit with Andrew Cowie about this. He's very interested
and he'll cooperate with people who want to do this (and based on his
enthusiasm, I even think he would co-develop it with that person). 

> - Perl bindings (low priority)

Muppet recently mailed some detailed instructions on how to get it done
on the mailing list.

> - .NET bindings (low priority, Bart is working on this and will soon
>   show us something)

As said, Bart is working on this. He's flowing his work into the
autotools environment. His current stuff is all shell scripts. He
successfully created a first .dll file for libtinymail.

He's also working on getting the other libraries language binded
in .NET.

Bart is a busy boy. You can certainly help him.

> - Support for virtuals in the Python bindings (low priority)

Tricky stuff. The idea here is to allow implementing a GTypeInterface,
as defined in the API of tinymail, in Python.

Same for all the other languages. I think all the language-binding folks
should at some point stick their heads together and work out a solution
for this. Cross project, I mean (not just for tinymail).


> - C++ bindings

I talked about this with Murray. He's very interested and will cooperate
with anybody who tries this. That's all I can say about this. He told me
that making it possible to implement GTypeInterfaces in C++ is already
automatically generated and possible with the environment that also
generates the gtkmm language bindings.



-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
blog: http://pvanhoof.be/blog