I spent two days last week at the trafficserver summit.

Or rather, two evenings.  The summit was held in Silicon Valley (hosted by linkedin), while I remained at home in Blighty with a conferencing link, making me one of several remote attendees.  With an 8 hour time difference, each day started at 5pm and went on into the wee hours.  On the first day (Tuesday) this followed a day of regular work.  On the Wednesday I took a more sensible approach and the only work I did before the summit was a bit of gardening.  Despite that I felt more tired on the Wednesday.

The conferencing link was a decent enough instance of its kind, with regular video alongside screen sharing and text (though IRC does a better job with text).  The video was pointed at the speakers as they presented, and the screen sharing was used to share their presentations.  That was good enough to follow the presentations pretty well: indeed, sometimes better than being there, as I could read all the intricate slides and screens that would’ve been just a blur if I’d been present in the room.

Unfortunately most of the presentations involved discussion around the room, and that was much harder, sometimes impossible, to follow.  Also, speaking was not a good experience: I heard my voice some time after I’d spoken, and it sounded ghastly and indistinct, so I muted my microphone.  That was using just the builtin mike in the macbook.  I tried later with a proper headset when I had something to contribute, but alas it seems by then I (and I think all remote attendees, after the initial difficulties) was muted by the system.  So I had something approximating to read-only access.  And of course missed out on the social aspects of the event away from the presentations.

In terms of the mechanics of running an event like this, I think in retrospect we could make some modest improvements.  We had good two-way communication over IRC, and that might be better-harnessed.  Maybe rather than ad-hoc intervention, someone present (a session chair?) could act as designated proxy for remote attendees, and keep an eye on IRC for anyone looking to contribute to discussion.  Having such a person would probably have prompted me into action on a few occasions when I had a comment, question or suggestion.  Or perhaps better, IRC could be projected onto a second screen in the room, alongside the presenter’s materials.

The speakers and contents were well worth the limitations and antisocial hours of attending.  I found a high proportion of the material interesting, informative, and well-presented.  Alan, who probably knows more than anyone about Trafficserver internals, spoke at length on a range of topics.  The duo of Brian and Bryan (no, not a comedy act) talked about debugging and led discussion on test frameworks.

Other speakers addressed applications and APIs, and deployments, ops and tools.  A session I found unexpectedly interesting was Susan on the subject of how, in integrating sophisticated SSL capabilities in a module, she’s been working with Alan to extend the API to meet her needs.  It’s an approach from which I might just benefit, and I also need to take a look at whether Ironbee adequately captures all potentially-useful information available from SSL.

At the end I also made (via IRC) one suggestion for a session for the next summit: API review.  There’s a lot that’s implemented in Trafficserver core and utils that could usefully be made available to plugins via the API, even just by installing existing header files to a public includes directory.  Obviously that requires some control over what is intended to be public, and a stability deal over exported APIs.  I have some thoughts over how to deal with those, but I think that’s a subject for the wiki rather than a blog post.  One little plea for now: let’s not get hung up on what’s in C vs C++.  Accept that exported headers might be either, and let application developers deal with it.  If anyone then feels compelled to write a ‘clean’ wrapper, welcome their contribution!