Concern

This is really neat: SmackBook Pro. The short of it is that you can, with a Mac notebook that has a motion sensor, switch between virtual desktops by slapping the side of your notebook.

This does need to be liberated from relying on non-free software, and it would be better if Desktop Manager (which I used to use, but gave up on for a while) worked a bit better on Tiger and x86. But heck, you could use the same mechanism to toggle Expose. Or even make it so if you shake your laptop a bunch, the windows on screen wander a little. It is a great UI — you get feedback on your computer to physical things you do to it. Probably more practical in handheld devices, though.

Also, at some point, someone is going to have to write an etch-a-sketch emulator for OS X.

One quick note that I’m posting my experiments with computer graphics, in the context of the class I’m taking now, on my Flickr page. CG is a lot of fun; you should take at least one course on it if you can.

I just looked at the actual schedule, and oof! The mid-term evaluation starts on June 26! This isn’t great for me, because classes at UCSC (for me) end on June 14! Bummer for those of us on a quarter system.

It may be tight to get something workable by then. But, I’m planning on taking the whole month of July off of work (I do have that much vacation saved up, and they owe me one), so I will have some time to catch up.

Also, I found out my mentor is going to be Tom Tromey. Nice to know I’ll have a capable, critical eye on this!

This project will, for the most part, focus on just providing an implementation of the JSSE API, as a provider, like Jessie does now. But, I thought it would be a good design to build it around a “pseudo-public” API, so a motivated user could extend TLS where they need to.

My current thought is to provide abstract API’s for:

• Session management and persistent storage. Jessie already provides some nice alternatives for storing SSL sessions: the default one in memory, but also one in a JDBC database, and one in a simple XML file. This doesn’t cover much ground, though, and someone might want to store sessions in some way we can’t anticipate. One public extension API would be a SessionStore class, which manages sessions, storage, expiration, etc.
• That implies having public APIs for concrete SSLSession objects. This is pretty easy, since session objects are more-or-less just collections of a handful of parameters. I will need to figure out some way to store Jessie’s private information in these sessions, though, and make sure that they get read back out properly when deserialized.
• Content-type handlers. SSL provides a generic content-type mechanism, along with four content-types that implement the core protocol (HANDSHAKE, CHANGE_CIPHER_SPEC, APPLICATION_DATA, and ALERT). But extensions to SSL can define new content-types; I think the delegation extension (which wasn’t published as a standard) did this, for example.
• Cipher suites. A cipher suite in SSL is basically the thing that encrypts, authenticates, and compresses records. There should be an API so people can write their own cipher suites, and plug them in.
• Certificate handling. There are the CertificateFactory and TrustManager APIs already, but we don’t have a good way to figure out which factory or trust manager we need. That is, if someone wanted to add SPKI certificate support to SSL, they need a way to register the SPKI certificate type with us, so we can look up the right factory when decoding certificates.
• “Your PKI has failed you” handling. You know, where you get a certificate that can’t be verified, or which has some problem with it, you get a box saying so and asking if it is OK to continue connecting. The javax.security.auth.callback package can handle this pretty well, but it can’t really do complicated things like multi-dialog confirmations, where you have an option to show the questionable certificate.

This is all only a sample of what’s possible, and it’s what is in my head right now. It would be nice to push these ideas to the JCP to try and make the JSSE really extensible, without GNU extensions. But, gee, I don’t know. The JCP people might burn us ponytailed GNU folk at the stake, or something.

SSL defines a number of protocol objects in the spec. These objects are specified as “structs” in the text, that is, an ordered list of named, simpler objects. An example may be:

struct {
  uint16 s;
  enum { foo(1) bar(2), ..., (255) } e;
  opaque o<1..256>;
} s;

This defines a layout of bytes, and attaches meaning to offsets into such a sequence of bytes, much like a C struct definition will. The difference is that the structure size isn’t constant: you don’t have pointers, so your variable-sized member data types really are variable sized, instead of being a pointer to variable-sized data.

In the previous version of Jessie, we did the obvious thing for blocking-IO users: we defined objects that matched structures, such as:

class s {
  short s;
  enum_type e;
  byte[] o;
}

…and we’d fill these fields in just by reading each type from an InputStream. A better way to do that, though, is to just use offsets into real byte sequences. And that’s what we’re going to do in the new version of Jessie: instead of copying types from the input stream into native types, we’ll just hold on to a ByteBuffer representing the encoded structures, as read from the socket, and provide getters and setters that just find the right offset into that byte buffer to write the objects.

This is nice, mostly because it requires no unecessary copying: you get a copy of the object when you need to read it as a native type; otherwise, it’s stored as it was read. Also, if you have a mutable object, changes you make to that object are direct: you change a field foo in an object, and that changes the underlying buffer. There’s no need to separate storage from encoding.

A problem with this is that editing an object has to be done carefully. If one field b follows a variable-sized field a, you must write a first, because otherwise you have no idea where b will go. This is probably O.K., because you usually only write a type of object once in the SSL protocol, so you know where to be careful, at least, or the objects written often are simple enough that it doesn’t matter. You also don’t really know that converting-on-access is saving you anything, because you presumably have to decode everything exactly once anyway.

That’s the approach I’m going to use, anyway. It seems conceptually clean, and very “hands-off” w/r/t the byte buffers we’re going to be getting as input.