Concern

I’ve gotten to the point where I’m starting to inch closer to being able to serve up a simple HTTPS request. It’s just a matter of time now, of fixing problems, compiling, testing, and analyzing in a tight loop. My only wish right now is that Classpath had a more efficient build system (especially in Eclipse!), because for each minute change, it takes a full autogen, configure, compile, header generation, and native compile! This is still pretty quick (it takes maybe 30 seconds or so to do all that on my laptop), but not as fast as I’d like it to be.

One nice thing is that I can use the old version of Jessie to test the new one. This means I can add logging diagnostics to the old code really easy, and get exactly the information I need out of both sides of the connection, instead of the cryptic error code FireFox gives, or the incomplete info GNUTLS prints out.

Onward!

Edit: figured out why Eclipse was building everything. See the comments for details.

I’ve started using the sample HTTP/HTTPS NIO server that Sun distributes with their JDK; so you don’t have to download the entire JDK, and to include some minor changes, I’ve packaged that sample code and made it available. It’s licensed under the two-clause “anti nuclear” BSD license, so it’s OK for me to do this.

Dear journal,

I got to have lunch at Google’s campus in Mountain View, today, along with a handful of other Summer of Code participants. It was fun. We ate food and talked to people.

Ironic introduction aside, it was kind of neat. I work in a depressing-ass cubicle farm in Sunnyvale, so seeing Google’s campus makes one gawk. It looks almost like a college campus, but everyone there is paid really well. I can’t help but regard it as almost cultish, what with that many beautiful, incredibly smart people hanging around a really cool-looking space — it’s like out of some sci-fi future, there’s got to be some kind of gag. I can’t help but feel like an ugly fuckup who wouldn’t belong there. But maybe there’s a basement.

They also have a huge number of people in a small space. No, check that, it is not a small space. It’s actually quite large. But they have a huge number of people and the buildings and parking are really crowded. They have valet parking in some lots, not because it’s Google and awesome, but because it’s fucking crowded.

I ate Indian food, which was really pretty good. It beat out the Indian buffet that’s across the street from us in Sunnyvale, but that isn’t hard to do. Someone else in the group had steamed oysters. It’s bizarre to eat this well in a corporate cafeteria. They had sodas with real sugar in them, not the corn syrup swill you’ll find everywhere else.

We got to meet Chris DiBona and Leslie Hawthorne, and listen to Chris chat about some things. They’re both nice. OK, Chris isn’t so nice, but he’s intelligent and tells funny stories.

Google are good people.

It came to me as a real flash of inspiration, and it seems exceedingly simple in hindsight, but I figured out what I need to do to implement handshake message output (see my previous post on this).

It’s quite simple really; boiling it down to a high-level algorithm:

if there is a buffered handshake fragment
  write bufferd data to output buffer
while we have a handshake message to write
      and there is space in the output buffer
  write the next handshake message to a temporary buffer
  write as much of this buffer to the output buffer as possible

This is kind of obvious, but the flash of we have to build each full handshake message in a private buffer was what made me grok the problem fully.

The only issue is that we don’t know, a priori, how big that private buffer has to be. The current API treats the underlying buffer as fixed: the caller allocates it, trims it to size, and swaddles it in the protocol code. Everything you write to a protocol object has to fit in the original buffer.

But, maybe, we could add a “resize mode” to each protocol object. So the caller can say instead “here’s a buffer. It may be too small to hold what I’m going to write to it, so if any setter call runs out of space, resize the buffer for me.” Very often we can tell if the buffer is too small very easily in all setters, and if we can’t, we can fall back to catching BufferOverflowException.

Adding that to the existing protocol objects wouldn’t be hard, but may be a bit ugly, and we might lose some opportunities for optimization on the read side (the underlying buffer can’t be final for one, but that probably doesn’t matter much). I think splitting the protocol objects into a base read-only class, and a readable/writable subclass, is the nicest, but that’s a lot of busy work that doesn’t make much progress on the library. And the deadlines, they loom, as deadlines are wont to do.

(This blog is kind of turning into my own TODO list, and impromptu note pad. I’m sorry if this bothers you, but no, I don’t care.)

The summer of code participants are getting a neat surprise in the mail: a notebook. Not that kind of notebook, but rather a leather (I think) note pad, whose cover is embossed with Google’s logo.

Just corporate swag, but neat nonetheless.