Date: 5/8/2004||I've been rewriting the layout of HTML tables in the control used by Scribe so that it can cope with the "webpage in an email" sort of junk that people receive. It's amazing how bad the HTML that gets sent in email's is, lots of nested tables and other lame layout tricks. Makes life really hard to support these emails in a secure, lightweight, cross-platform manner.
So far it's looking pretty good. Pages that just wouldn't render are comming up reasonably well. I'm using the CSS2 table layout algorithm as a base and then hacking on the necessary bits as I need to, so that it works. There is a lot of things not really discussed in that algorithm. It's too breif, and I'd like to know if there is a most complete HTML table layout algorithm.
In the meantime if you have HTML content that doesn't render in Test19 (not yet released) then you can send it to me by right clicking on the HTML control, selecting "Copy Source" and pasting that into a text file. Attach that to a bug report email to me. I'll add it to my test suite and see what I can do to get it running.
|(0) Comments | Add Comment|
|3 Types Of Creatives|
Date: 3/8/2004||Most of my friends would agree that I'm a creative person. Who I am revolves around my coding and music skills. Sometimes people are really only aware of one side of that divide, like my co-workers. Anyway I was thinking the other day that I catagorize people into 3 types, in terms of their level of talent and ability. Firstly there are the truely talented, then you have the dedicated and finally the talentless. Which might sound harsh but hear me out.
'Talented' people are those who come along, pick up an instrument, a brush, a mouse or a pen and in seemingly no time at all start bashing out amazing works of art that people gawk at. It seems very effortless for them to create very good work, and they become good at what they do very quickly. I know a few people that are truely talented, and yes they work hard at it but what I'm getting at is that they have a very good return on their work as well.
Then there are the 'dedicated' people that work for years and years on their chosen skill, gradually getting better and better, and eventually doing something really good with their medium. They are characterized by being very stubborn and not giving up. What they do doesn't seem to come naturally to them and they can't adapt quickly to new challenges, but nevertheless they do eventually "get there".
Finally, the 'talentless', and you can probably guess where this is going. They never get even a little bit better, they slog away at something for years and at the end are still within arms reach of where they started. It's almost depressing watching them struggle trying to grasp the concepts and skill required to execute in their medium.
Now your probably wondering what catagory I put myself in, and well I'm one of those 'dedicated' types that spend their life slowly getting better at their art. The funny thing is that the dedicated types often go furthur than the talented type simply because they have far greater stamina, because without that they don't get anywhere at all. They don't get anything handed to them on a plate, it's all very hard work, so they just have the staying power to reach their goal that not all the talented types have. Nevertheless some talented types do have that as well, and of course they blitz everyone else. *sigh*
Maybe you could add a 4th catagory for all the people that are so apathetic that they never try in the first place. But they aren't really 'creatives' after all.
|(3) Comments | Add Comment|
|POP over HTTP|
Date: 3/8/2004||If you not already aware of Scribe's POP over HTTP protocol then it's a way of routing POP traffic over the web so that if you stuck behind a firewall that only allows web traffic you can still get your email. The only downside that you need a PHP server somewhere to host the script that bundles the POP mailbox data into webpages. Although it doesn't have to be on the same server as the POP account, it works so much better if it is on the same server. The reason why is latency. When the script is loaded on to the same machine as the POP account it runs really fast, so much so that your entire mailbox downloads in about a 10th of the time it normally takes. Thats because the POP protocol is not designed for laggy connections and POP over HTTP removes almost all the lag by batching commands and responses together.
Anyway considering that it's not easy for everyone to host a script somewhere, I am considering setting up a service that does just POP over HTTP. You'd get a mailbox on a server that allows you access using POP or the POP over HTTP protocol. You'd have to change your email address but for some people that'd be worth it. There aren't any insurmountable technical issues. So it'd be just a matter of setting up a domain and writing some PHP glue code to setup and configure accounts. I think I would probably have a free account with a small mailbox size, say a few MB and a commercial account with more MB's and maybe other features like virus removal or whatever. As for pricing I'm thinking maybe $5/yr. But I'd have to do some figures to make sure that is sustainable.
What do you think? Is it worth setting up? Is there enough interest?
|(6) Comments | Add Comment|
|Threading and locking|
Date: 2/8/2004||I've been learning about some of the less obvious aspects of threaded code. Normally when you use threads to access common data you have a semaphore or mutex surrounding the resource so that only one thread can access the resource at any given time. Well thats the theory side of things. Seems fairly simple, you lock the resource, use it and then unlock it.
Well it isn't that simple (is it ever?). Due to the way locking is implemented in my own applications, one thread can hog the resource simply by locking and unlocking it too much. I have an example with 2 threads, the gui thread which is running the application's message loop wants to lock the resource once a second and the worker thread that is locking/unlocking the resource in a tight loop. The worker thread can always aquire the resource and the application thread can never acquire the resource. It seems if the period of time between the worker thread unlocking the resource and it relocking the resource is too small then no other thread has a chance to lock the resource.
Which in the case of Scribe means that the application's message loop locks up for up to 20 seconds. Which hangs the application... So I've been inserting sleeps into the worker thread code to leave air gaps for the application thread to aquire the resource and function properly.
This of course is a "hack" to make the application function, but in the long term the semaphore should be rewritten to play nicely. I'm not sure yet as to whether this is an artifact of my own implemenation of semaphores or it's an actual issue with semaphores in general. The other obvious thing is to reduce the amount of locking that the worker thread has to do. Which is an obvious gain in efficiency as well but would require more invasive changes to the code base than I really want to attempt while working on a stable release.
Speaking of which, Test18 hasn't received any reports of crashes or other nastyness. So I'm going to clean up a few cosmetic things for Test19 and release that as the new "Stable" build for Scribe. If you have any show stopper issues in Test18 please let me know.
|(1) Comment | Add Comment|
Date: 2/8/2004||Well most things are back to normal after moving hosts (again). This should be the last time I move hosts for a long while.
If anything is broken drop me a line and I'll sort it out.
|(2) Comments | Add Comment|
|Defensive Web Programming|
Date: 27/7/2004||I had to do some more defensive PHP programming today to stop the crazy GoogleBot from loading random non-existant URI's on my site and filling the stats mechanism up with junk. It seems to be the worst of the bots in that regard. If it was anything other than Google i'd just block the bot in the robots.txt or even by hostname but I guess I like my site being indexed by Google. ;)
I still remember the day that GoogleBot went postal on me and got stuck in a loop loading weird URI's off my site made up of combinations of bits of path and script names. 61000 times. Thats a lot of page loads in one day.
These days it's just a few pages here and there but still annoying enough to detect and fix. Btw I found a bug in PHP to, if you go to a page in the form 'http://site/page.php/' the $PHP_SELF variable has '/' in it. Instead of '/page.php/' or something. Dumb PHP.
|(0) Comments | Add Comment|