Blog
Progress
Date: 31/10/2006
I've refactored the SSL implementation in Scribe v1.89 test7 a bit. Basically I reuse the one SSL_CTX object allocated with SSL_CTX_new for the lifetime of the application instead of for just one connection. I also made the mistake of deliberately freeing the SSL object that I retreived with BIO_get_ssl. Obviously that belongs to the BIO object or something, because when I freed the BIO object with BIO_free_all it seems to free the SSL object as well. And if you try and free the SSL object after that it crashes.

End result is that now it seems to be working fine. No crashes, just normal operation over time. I'm just keeping it connecting regularly to test it over the next few days.

The state of the core components of Scribe is getting more stable now after ripping out the old options system and implementing a new one. There is one area that hasn't been fixed up yet and that is the plugins option storage. Currently they use this weird indexing system which won't be compatible with the new XML options file. So I'll have to rewrite that over the next day or 2, and then test it.

There is now a new more robust method to save Window state (position and min/max) to an option file and built it into the GWindow object. This should mean that over the next release or 2 window positions become more reliable on a wider range of systems. Hand in hand with that I've fixed the "MoveOnScreen" method of the GView class to handle multiple monitors (at least on Win32) in an intellegent manner. And I plan to do the same sort of magic on the "MoveToCenter" method to avoid it going to the wrong screen or the edge of 2 screens. It should center on the same monitor as the other windows in the application. More or less.

I'm playing with the idea of offering an option to store mail, contacts and other objects in a Maildir style folder instead of all in a mail2 file. This has some benifits and some drawbacks but I think the benifits outweigh the drawbacks. In the long term I'd like to move fully away from the mail2 file format. But I worry that some users need the benifits of it, especially people that use space limited USB drives will get hit with wasted space per node due to file system limitations. I don't know how bad that'll be yet but it might be a problem. The benifits are mainly, opportunity for corruption is very limited and easily fixed, you still benifit from being able to move large email around effortlessly, deletes are easy and quick (unlike MBOX) and it's mostly compatible with other mail clients that support maildir. It's tempting. One question I havn't fully answered is whether I should attempt to support both at the same time or just drop mail2 all together. You might like to weigh in with your opinion in the comments.
Comments:
Rien
31/10/2006 2:06pm
Having installed i.Scribe a while ago, I wondered about this mail2 format. It may be more compact than others, but it's also uncompatible with just about everything. I really prefer a more 'normal' mail format.
Josh
01/11/2006 6:05pm
I know I would prefer the Maildir format, but I'm not sure if everyone would. I'm sure I wouldn't like my memory card suddenly "getting smaller" because of a simple change in mail storage format. (I use an HD install, not memory card)

But, I also like the convenience of just having to back up a single file, rather than an entire directory. On the other hand, if anything were to go wrong, it's easier to use a compare program to compare 2 sets of directorys to see what's missing than to try to compare 2 binary files.

All that said, I think the Maildir format would be better, but you'll probably have people who still want the mail2 format.
 
Reply
From:
Email (optional): (Will be HTML encoded to evade harvesting)
Message:
 
Remember username and/or email in a cookie.
Notify me of new posts in this thread via email.
BBcode:
[q]text[/q]
[url=link]description[/url]
[img]url_to_image[/img]
[pre]some_code[/pre]
[b]bold_text[/b]