Re: [Evolution-hackers] Moving the struct instance heap space to mmap

[Philip Van Hoof <spam pvanhoof be>]

Hi there,

I'm going to cut quite a bit to keep the discussion readable. If others
are following it, please read the full messages that came before this
one.
 
> Hmm, well I think camel is a bit too complicated. It makes it
> difficult to implement backends for the interface.  Well, maybe a
> little bit more difficult than need be.  But I suppose not many mail
> clients try to throw 100K+ message folders at a treeview, and expect
> it not to use a lot of memory.

I have this naive idea that phones of tomorrow will have much more
Internet related functionality than today's modern desktops. In a much
more integrated way. I believe people hate desktops but enjoy the
applications on top of it.

Like how iPods are designed for playing music, car navigation designed
for bringing you to your destination, DVD players for ..., cameras
for ..., etc

If that naive idea happens, there will be a huge demand for mail clients
that can show 100K+ messages yet not use a lot memory. 


> But if it's too complex to use or maintain, then it is more wasted
> effort.  I'm becomming much lazier in my older-age perhaps!

My reason is the technical challenge and the enjoyment of trying to make
a difference. The path to it, not the result. It might make it more
difficult for me to view things as wasted effort (but I'm also young and
naive).

Perfect is anti-perfect because then it lacks the possibility of
improvement.

It's fun and fuelling to watch people use it. That is true.

> Having extra indices on disk - you're really just writing datbase
> table - and all of the associated complexity, consistency and
> coherency issues that implies. 


I wouldn't be against using one of those 'embedded' database engines
like sqlite3*, mysql-embedded or db* and ask for a cursor at the model
impl of a treeview.

* sqlite3_prepare(), sqlite3_step(), sqlite3_reset() etc etc

I fear copying the entire query result in the memory of the application
(how most developers use databases in their apps) wouldn't reduce memory
consumption at all. Launching a full new SQL query each time a row
becomes visible, is going to cost a lot in performance. Since sorting
would be done at the db, it might indeed be 'fast enough'. On a mobile
device, screens are small. Amounts of visible headers too. 20 queries
isn't a lot.

> Maybe gtktreeview changed since i last looked at it.  It was rather
> slow too, iirc.  There's only so much virtualisation you can do with
> tree's anyway, some of the data you need all of the other data to
> calculate - unless you keep another on-disk index in 'tree sort'
> order, and virtualise even that. 

Sorting is indeed still a pain. Showing once the model is sorted isn't
anymore with the current gtktreeview and fixed-row height turned on. 

The cursor idea and a db engine might be a quick solution for this.
Databases are often very good at sorting stuff.

> > Thanks a lot for your point of view Michael. I value it.

> Well you've piqued my interest ever-so-slightly in mail things again,
> but I'm not sure - i'm not sure I really want to get back into coding
> it again, at least.

Well, it's a start ;)

> It would be more fun writing something a-new than trying to fix
> something else, and particularly having to worry about client
> compatability. 

Jeffrey is (or has been) (as you probably know) working on libspruce. A
fresh Camel with input from those people who made a good E-mail library
already, would definitely be something I'd both enjoy using as a devel-
oper and co developing of necessary (I like getting my hands dirty).

I, however, realize that I lack field-experience to make such a thing my
one person show. On top of that it's quite a lot man-years of work to
have something that works only a little bit better than current Camel
(and not as significantly better that people would pick it over Camel).

I'm experienced enough to realize that ;). I didn't start tinymail as a
specialist in E-mail. Which probably explains why I'm doing so many
refactor iterations. But redesigning is imo okay. I just called it
"Agile" as explanation why redesigning and rethinking is important. Not
being afraid of changing things is in my opinion important.

It's a problem the Evolution project is, I think, experiencing. But I'm
powerless when it comes to Evolution. I look at Harish and technical
Novell decision makers and Novell management to solve this.


-- 
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