If people would like to get together anyway, despite the cancelled meetup, let's use this entry to arrange a time and place. :-) I was thinking of doing that anyway, and then droleary suggested it as well, so I'm all for it. :-)

I bought a new PowerBook as well, so I'd have a toy for people to ogle. :-)

I'll be working for Amazon in Seattle. I'm going to have to move. So please, people here in Minnesota, sign up for this month's Slashdot meetup so I can say goodbye to you all before I go. :-)

Well, I'm off to my job interview with Bloomberg in NYC. Wheee!

Well, I have a name for my project, and a website. It will be known as CAKE. :-)

I need to set up a Wiki and a mailing list for it, and some other ways of getting feedback from people. I want to build a community around this project fairly quickly as there will be a number of aspects of the project that others would be much more suited to attacking than I.

Well, it's starting to come together a bit, and I'm needing a name. I'm building a protocol in which all objects are named with self verifying names that aren't human readable. Messages are sent to a public key, and are always signed by the sender's public key. Files are named by secure hashes of their contents. That kind of thing.

I have grand plans of using this protocol for email, instant messages, web browsing, remote filesystem and database access, and almost anything else you can imagine. I intend for the basics of the protocol to form a layer above TCP or UDP, though it should be able to be layered inside of almost anything. I intend to write layerings for SMTP/IMAP, and AIM/Yahoo/MSN/ICQ/Jabber (via a gaim plugin).

I have some of the basics working using a mixture of C++ and Python, but it's not quite ready for public consumption. One obstacle is a name. I made a post in my LiveJournal about naming it. I'd like input from people here, if they're interested. Please feel free to make posts (anonymous or otherwise) to my LiveJournal with opinions or suggestions.

I don't consider the non-human readability of the names to be an obstacle. After all, IP addresses aren't particularly human readable either.

Also, if you care to look at the source at it currently stands, it can be found at: http://www.cakem.net/

Subversion is great, and MUCH better than CVS, even though it's still in alpha/beta.

*sigh* The company I used to work for is barely staying afloat. They decided to jettison more development staff today in the attempt. They cut some really excellent people today. They won't be able to move things forward much at all now with so few people. :-(

Oh, well.

If anybody knows someone in MN who wants a really good C++ programmer who also knows enough Unix administration to be a good sysadmin, and who knows Python, Perl, some Java, and a whole slew of other stuff, post them here. :-)

Well, my XML parser understands XML well enough now to turn this:

<fred> <went> <down> <to> <the> <street> </street> <br/> </the> <a><store></store></a></to> </down> </went> </fred>

into this:

<fred>
  <went>
      <down>
        <to>
            <the>
              <street>
              </street>
              <br/>
            </the>
            <a>
              <store>
              </store>
            </a>
        </to>
      </down>
  </went>
</fred>

Yeah, maybe it doesn't seem like much, but in order for the code to do that, it has to understand what a start tag looks like, what an end tag looks like, and what an empty tag looks like. It also has to keep track of the nesting level.

I'm happy about all this because the parser is carefully designed to for two requirements. The first requirement being that it be as fast as possible. The second being that it give me pointers into the original text where the various elements and tags are. The second requirement allows me to cut out or replace pieces of XML documents without altering the parts I'm not changing.

Since the XML messages I'm working with may have pieces that are digitally signed, it is vitally important I leave them exactly as I found them. Any alteration, no matter how slight, would render the signature invalid, and the message would be rejected by the destination. Most XML parsers forget the original document as they construct an internal structure describing the various elements and their relationships that throws away superficial features (like spacing) found in the original document.

Anyway, I'm pleased with my progress. I've had to stop for careful thought along the way to make sure that it was as flexible and fast as possible. I think it'll be fairly widely useful when I'm done.

Despite 8 people claiming they'd show up, only 3 actually did. It was still fun, but still something of a disappointment. Especially after I reserved a table for 6-12 people on Wednesday. :-(

I wish meetup.com had a way of leaving feedback for other people who claimed they would show up.

I'm trying to convince various groups I work with to start using Wiki's to collaborate. They seem like a collaboration method that has an impressive degree of flexibility and open-endedness. It makes them kind of fun to use and quick to create.

I've put up a Wiki for my homepage, and am hoping I get random people writing in it. :-) I should probably stick links to and from Wiki pages to documents in my technical section to try to spark debate and ideas.

I've been discovering how bad XML is for designing protocols. For some non-technical reasons, I decided to design my next protocol in XML, and taught myself a lot about it.

Aside from the bloatedness of a tag system, the main thing about XML that makes it totally unsuitable for protocol design is its lack of a decent way to do enveloping or encapsulation.

Most protocols will carry data that has nothing to do with the protocol. They will be used in some capacity as a transport. XML makes it very hard to design protocols that can do this easily.

Anyway, this is less well written than I hoped, but I think my point is clear. :-)