|Bruised Ego More Than Car|
Date: 28/2/2005||This is what happens when your tired, in a rush and not paying enough attention:
The dull sound of impacting metal is probably all familiar to our ears. But still it's surprisingly distasteful. I was entering an intersection from a very steep upward hill and looked right as I was approaching, then when I reached the threshold I saw a car off to the left that was moving very slowly. I took a lot longer than normal to decide whether to go before that car or wait for it because it wasn't moving at normal pace, nor was it still. In the time it took for me to make a decision about the car on the left someone had come around from the right, previously obstructed from view by the crest of the hill, and I clipped the rear of their car. I'm not sure whether I'd commited to the intersection or I was just rolling along. But it's all pretty academic now.
It'll probably cost me about A$ 1000 in insurence excess and higher premiums over the next 2 years. A painful reminder to take your time and not make assumtions about your surroundings on the road. But as everyone says "at least everyone was ok". I did more damage to myself (cut my finger) changing their flat tire than in the accident itself.
I witnessed first hand a semi-trailer run a red and collect a car a few months ago, probably killing the car occupant. When I saw her last the driver of the car was jammed up inside the cabin, bleeding but moving ever so slightly. A sight I'll carry for the rest of my life. Anyway the point of that was that I've been trying hard to keep my eyes open when crossing intersections for traffic. And now this! *sigh*
|(0) Comments | Add Comment|
|More Windows XP Madness|
Date: 27/2/2005||Everyone knows by now how much I love Windows XP, even to the point of writing an application to fix the file associations. But it's come to my attention that fixing the associations is not enough, Windows has to "fix" them back everytime I log in. Doesn't it. Just to be a complete and utter pain in the. What possesses them to write such a horrible mess of an OS?
I'm dreading being finally forced to upgrade my machine at home from 2k to XP so I can use some new hardware that I just bought. I'll be able to experience the pain in all it's delightful glory, up close and personal.
That is of course until I get my hands on one of these. In your face XP! And as a nice side effect the computer won't sound like a wind tunnel. I'm getting sick the cooling requirments of Athlons.
|(1) Comment | Add Comment|
Date: 18/2/2005||I've had a lot of interest in getting Scribe's SSL Plugin working with OpenSSL on a USB key drive. The main problem is that you have to install OpenSSL on the host machine for it to work. Well I uninstalled OpenSSL on my desktop, and worked out how to make it work with just part of OpenSSL in a directory relitive to Scribe's exe. If you have just DLL's (libeay32.dll and ssleay32.dll) in "..\\OpenSSL" it works.
So with the next release of Scribe you should be able to take OpenSSL on the road with you. I'd like to hear from you if you have this working or not when I release it.
|(1) Comment | Add Comment|
|Mac + PC + Big Files|
Date: 16/2/2005||I've got some friends that want to move large files (video) between Mac's and PC's in different locations. We're talking 10+GB files. So anything that uses FAT32 is out. And anything that the computer mounts directly, say over USB2 or Firewire means the filesystem has to be compatible between both Windows XP and Mac OSX, for writing as well. Which currently isn't the case, NTFS can't be written by a Mac.
So I'm thinking if I could find something that attached to a 10/100 LAN, accepted Samba/SMB connections and used NTFS internally on a 3.5" drive, it should work seemlessly between the Mac and PC for large files right?
Anyone know of such a beast? (Lots of devices are close - i.e. do all that but are FAT32).
|(10) Comments | Add Comment|
|Todo List For Scribe|
Date: 16/2/2005||Well I finally wrote a todo list into Scribe:
Please tell me there are some other apps that read/write VTODO objects?
|(2) Comments | Add Comment|
|Perenial Design Issues In An Email Client|
Date: 14/2/2005||By most accounts Scribe is good. Some even say excellent. But there are some "grey" areas that still need addressing. And what I'd like to do is put forth the problems and ask my knowledgeable readers their opinion on possible solutions and expectations.
Temporary Files Ahhh, the age old question of temporary files. Or Scribe's use in a particular situation to be more precise. When a user receives an attachment they often want to open the attachment, usually in the default viewer for that file type. Because Scribe stores all data in a single folders.mail2 file it has to write the attachment out to disk for another application to be able to receive the data. So it writes the attachment into the temp folder and starts the associated application to open the file. Now the catch is when the user edits the file they usually don't realize where the file is, i.e. in the temp folder. Then they save there changes into a temp file.
At the moment Scribe produces a new unique filename every time the user opens the attachment to save losing the changes they may have made to the original temp file. It doesn't clean up after the user because they may want the temp file changes. So we end up with a ever increasing set of saved attachments in the temp folder.
I want a system that a) lets the user open an attachment with out specifying a folder to save to, b) doesn't blot over any changes to the file once it's saved somewhere and c) allows changes to the attachment be incorporated back into the email client when appropriate (say in a reply or forward to the original attachment's email).
Rich Editing Everyone at some point wants to do some basic styling or layout of text in an email, Scribe users included. Now Iíve tried several times to write a decent rich text editor based on the existing compose control. And well I suck at it. So Iíll lay down my parameters for a rich edit control and see if anyone knows of something that will fit:
Summary Listings One of the major speed bottlenecks of Scribe at the moment is when it loads a folder of objects (esp email) it expects to have access to the entire object (email). Including the body of the message. The problem with this is that itís bound by disk speed and on large folders that bogs it down a lot. Large message are read in entirety (sans attachments) into memory, costing Scribe time and RAM. Now itís going to be really hard to make it not do that because I would have to rewrite lots of the architecture to make it not read the whole message. Now I could move the body of the message into an attachment of the message, which would mean the size of the ďmailĒ would be much smaller and thus folder read speed could be vastly improved. As a nice side effect compatibility with other mail formats (like MBOX and .EML) could be improved at the same time.
The question is whether to do this now in the v1 code base or leave it to v2. If I do it now with the v1 code base itíll mean staying with v1 for a lot longer, as itís the worst of the architecture problems. If I do it in v2 it might not happen for a long time. Gee Iíve only been talking about v2 for 3 years. V2 brings with it a whole swath of nice features. The less work I have to do on v1.xx the more time I have for working on the v2 prototype code base. Is there some overriding sentiment in the user community either way?
|(3) Comments | Add Comment|