Re: New todo summary

[Philip Van Hoof <spam pvanhoof be>]

And more testing of recently added API:

- tny_folder_copy
- tny_folder_transfer_msgs_async

More API that is yet to be added:

- tny_folder_store_remove (self, child_folder)
- tny_folder_copy_async
- tny_folder_remove (self, child_msg)
- Maybe also a tny_folder_store_remove_async? Is this overkill?

- ... (don't think that that's it :p, it's not it)

To make a long story a little bit shorter: yep, I can use your help :)


On Mon, 2006-12-11 at 16:35 +0100, Philip Van Hoof wrote:
> 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