A few easy tasks

[Philip Van Hoof <spam pvanhoof be>]

There are a few more easy tasks to do for tinymail:

Brainstorming about private data.

The thing is that a lot of the private data is needed when you inherit a
type. For example the new TnyMsgRemoveStrategy allows the end-developer
to specify how exactly tinymail should remove messages. View it as a
pluggable system (you plug-in a new strategy for removing messages).

On one device using one specific account-type, the end-developer might
want to decide to always permanently remove messages upon each removal
instruction. With another device or/and another account-type the
end-developer want want to decide to flag the message for removal upon
next expunge.

To implement such a strategy, the end-developer sometimes needs access
to for example the CamelFolder instance. This is a private member of the
TnyFolder implementation: TnyCamelFolder. At this moment this member is
in the tny-camel-folder-priv.h header. This header isn't installed.
Which implies that it's effectively impossible to access it (unless the
end-developer does a hack like manually calculating the offset to the
pointer).

I also don't want to support any promises about backward compatibility
or member-positions in these private headers.

I'm thinking about installing them in $(inc)/libtinymail-camel-1.0/priv/
and adding a #warning that says that API changes WILL happen in future.

For that I need monkeys who want to add such a warning everywhere, who
want to brainstorm about how to do all this correctly (all the header
wizzawazza), monkeys who want to fixup the Makefile.am files, stuff like
that.

OR I need monkeys who want to help me add data accessors like a
	CamelFolder *tny_camel_folder_get_camel_folder (..)
that will return that instance in a correct and secured way.


Both is monkey work, and both will get yourself deep into tinymail's
code and implementation rapidly (you will see very quickly how
everything is put together).


There are also other such locations and other such situations.
Especially in the libtinymailui-gtk implementation library (most people
will inherit from these types).

For example making most methods virtual (which isn't easy in GObject,
but I can teach you --it's not as easy as putting "virtual" in front of
the method name, no. You need to store the function pointer
somewhere--).


All great monkey work. Urgent to do items. And yes, my todo list is
extremely huge, so I can indeed use your help with this.


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