IT'S OUT. Get it, it's the best one yet.
Quotient 0.7.0
We're making really good progress now, but we have GOT to stop these
midnight releases.
Timezones are more complicated than I had hoped, but less than I'd feared.
At least, some of them.
All the confusion stems from daylight savings time, which is, I might add, a terrible, terrible idea. US time and European time are just subtly different enough to be annoying, but they don't have anything seriously surprising in them.
Python's spiffy new datetime module is aware of these issues, and apparently wishes to avoid becoming embroiled in the hothouse world of temporal politics. Odd design choice, considering that the language was designed by a time traveler. While this is irritating from the point of view of someone who wants to just stuff some date objects into strings formatted appropriately for different time zones, I can see why. The amount of work you'd need to do to properly support every time zone is staggering.
For example, it turns out that israeli daylight savings switch-over time is set every year by the ministry of the interior, so you can't actually anticipate it in software, only retroactively apply the dates.
I have no idea how japanese, russian, african, or chinese dates work yet, and I'm not really looking forward to find out unless it's in the form of a robust
All the confusion stems from daylight savings time, which is, I might add, a terrible, terrible idea. US time and European time are just subtly different enough to be annoying, but they don't have anything seriously surprising in them.
Python's spiffy new datetime module is aware of these issues, and apparently wishes to avoid becoming embroiled in the hothouse world of temporal politics. Odd design choice, considering that the language was designed by a time traveler. While this is irritating from the point of view of someone who wants to just stuff some date objects into strings formatted appropriately for different time zones, I can see why. The amount of work you'd need to do to properly support every time zone is staggering.
For example, it turns out that israeli daylight savings switch-over time is set every year by the ministry of the interior, so you can't actually anticipate it in software, only retroactively apply the dates.
I have no idea how japanese, russian, african, or chinese dates work yet, and I'm not really looking forward to find out unless it's in the form of a robust
tzinfo implementation...
A few people have asked me for the web comics I read this week. Here is a
sampling:
This week I've been in New York City with the rest of the divmod developers, trying to get our product
(service, really) into an acceptable state to start selling it to
people.
Aside from some really unfortunate personal issues, this has been easily the best week of the last year. Every day I sat down to do some work, every day I got something quantifiable done. There are design issues, but there was no thrashing between completely different ways of doing things, only subtle corrections of possible problems.
Even the one really frightening thing that happened this week, a DB_RUNRECOVERY error which spuriously appeared when we attempted to open our database file, turned out to be a peculiarity in the interface of bsddb and not a systematic problem. JP and I managed to get the database re-opened and uncorrupt just by reading the mnet source code and tweaking some variables.
The two stars of this week were really "atop" (atomic transactional object persistence), and "nevow" (pronounced "nouveau", the next version of woven). After a week of intense work, we have a new UI and a new database: the new UI is almost to the point where the old one was, and the new database is far beyond the point where the old one was.
Despite this, there's a huge amount of work remaining, especially to rewrite our input handling and such. Still, I estimate at this point that I'll be keeping my email in this system in 2 weeks or less, and I'm far more sure of that estimate than I have been at any point in the past.
Aside from some really unfortunate personal issues, this has been easily the best week of the last year. Every day I sat down to do some work, every day I got something quantifiable done. There are design issues, but there was no thrashing between completely different ways of doing things, only subtle corrections of possible problems.
Even the one really frightening thing that happened this week, a DB_RUNRECOVERY error which spuriously appeared when we attempted to open our database file, turned out to be a peculiarity in the interface of bsddb and not a systematic problem. JP and I managed to get the database re-opened and uncorrupt just by reading the mnet source code and tweaking some variables.
The two stars of this week were really "atop" (atomic transactional object persistence), and "nevow" (pronounced "nouveau", the next version of woven). After a week of intense work, we have a new UI and a new database: the new UI is almost to the point where the old one was, and the new database is far beyond the point where the old one was.
Despite this, there's a huge amount of work remaining, especially to rewrite our input handling and such. Still, I estimate at this point that I'll be keeping my email in this system in 2 weeks or less, and I'm far more sure of that estimate than I have been at any point in the past.
Brian Warner dropped by today and we spent a good chunk of the day speccing
out New PB. The New PB will resolve pretty much all the security issues I've
come up with in the long purgatory of implementation-less contemplation of
my previous work, plus it gives us a good place to define all *kinds* of
wacky transport semantics that would otherwise have made the old
infrastructure blow up.
In brief, every object that you want to publish remotely will have a schema or interface that specifies how it is serialized or referenced remotely. We will be trying to produce arbitrarily publish-able objects that have both state and methods, where you can say how you want to send things by default, but you can also switch it up in different situations without defining a bazillion classes.
The only lack of convenience is that we are going to spit out a near-continuous stream of warnings if you try to go for the "arbitrary graphs of objects" behavior that the previous version allowed. Sorry, folks, but that's just not safe in python and it can never be made safe :). However, we will still allow it for prototyping purposes, and maybe even add a mode where the system spits out an example schema after you run "trial" over unit tests that invoke the PB serializer on a particular set of classes.
We also discussed his "Pet Mail" project, which is a replacement for SMTP. It got me thinking about how poorly defined our shared vision for Q2Q is. We've really only started the very basic design discussions. Brian's project is a really good example of the kind of straightforward crypto work that we haven't had any time or inclination to do. However, it's (explicitly) got no deployment considerations, so if we can leverage some of the planned features of Q2Q and Quotient to get the base PetMail protocol widely deployed, we can establish a shared, clear basis for verified personal communication. Divmod can build more interesting applications on top of that, but it would give us a simplified transport layer to sell to other ISPs so that we don't need to spend all our processing power and disk on brute-force spam filtering.
In brief, every object that you want to publish remotely will have a schema or interface that specifies how it is serialized or referenced remotely. We will be trying to produce arbitrarily publish-able objects that have both state and methods, where you can say how you want to send things by default, but you can also switch it up in different situations without defining a bazillion classes.
The only lack of convenience is that we are going to spit out a near-continuous stream of warnings if you try to go for the "arbitrary graphs of objects" behavior that the previous version allowed. Sorry, folks, but that's just not safe in python and it can never be made safe :). However, we will still allow it for prototyping purposes, and maybe even add a mode where the system spits out an example schema after you run "trial" over unit tests that invoke the PB serializer on a particular set of classes.
We also discussed his "Pet Mail" project, which is a replacement for SMTP. It got me thinking about how poorly defined our shared vision for Q2Q is. We've really only started the very basic design discussions. Brian's project is a really good example of the kind of straightforward crypto work that we haven't had any time or inclination to do. However, it's (explicitly) got no deployment considerations, so if we can leverage some of the planned features of Q2Q and Quotient to get the base PetMail protocol widely deployed, we can establish a shared, clear basis for verified personal communication. Divmod can build more interesting applications on top of that, but it would give us a simplified transport layer to sell to other ISPs so that we don't need to spend all our processing power and disk on brute-force spam filtering.