[Purdue release];

So for those who weren’t already aware, on October 7th I gave my two weeks notice to my supervisor at Purdue. After just over 21 months, I was ready to be free of that place. Well, I was ready to be free much farther back than that, but I was finally presented an opportunity too good to pass up in favor of the stability and large perks that Purdue offered.

Without me going off the bitter deep end (not that anybody would be surprised by that), my reasons for leaving were barely a secret to my coworkers. Between the politics, some of the people (particularly the upper management, or at least the decisions they had made), and the uncertain future ITaP presents to its employees, not to mention the day-to-day frustration of being a Windows admin, the job as a whole was taking its toll on my sanity and the rest of my life.

So with that, I wish the best to my colleagues and friends still working for ITaP and various other Purdue IT groups, and I do hope they all stay in touch, if for no other reason than so I have a conduit of information as things continue to slowly fall apart. Hopefully that will stop happening soon, but you can’t hemorrhage good people the way ITaP has been and continue to do good work. The handful of knowledgeable, competent people left behind can only be stretched so thin. I do hope sanity is restored at some point, for the sake of those too embedded, too enamored, or too stubborn to leave.

[[Stoneware alloc] init];

So the opportunity I mentioned above, the one that was too good to pass up? I started there October 25th (yesterday, by my clock). Its with a little company called Stoneware, based out of Carmel, Indiana. Without going into too much detail, they were looking for a developer familiar with Microsoft’s Remote Desktop Protocol (RDP), more specifically somebody who had experience working on a client, and given my experiences with CoRD over the last 18 months, my proximity to the company, and my dissatisfaction with my current job, neither the timing, nor the job, could have been a better fit.

I’ll be commuting to Carmel as needed, but predominantly working from home. I spent most of yesterday in meetings and most of today sifting through code and getting my bearings on where things are. I’ll be working entirely in Java, at least for now, so its a bit of a leap, but the experiences I gained this summer ginning up some C# apps for our Windows 7 migration are paying off already, given the similarities between C# and Java (for once I’m happy Microsoft ripped a good idea off of somebody else). I will say that despite missing Objective-C at times, I’m excited about the opportunities the job has, and the more I dig into things, that excitement only seems to grow.

[CoRD setStatus:"Uncertain"];

We haven’t really discussed the future of CoRD yet at my new job, and I’m not really certain where things lie. Given how busy spring and summer, and even the fall was for us at Purdue, trying to get our Windows 7 migration underway and off the ground, I had barely any time to put forth towards CoRD. I did some experimenting at various points, trying to get some of the larger features we planned to implement at least started and/or off the ground, but at this point none of them are outside of the experimental phase. There was just too much work involved in the bigger pieces, and I didn’t have the time or gumption required to go through, rip out all the dirty code, and replace it with some sparkling new awesomeness. Given that working on it now would present a conflict of interest (potentially), I’m not sure where that leaves CoRD. Dorian has expressed an interest in keeping the project alive as needed, but I got the sense that he had no plans for large changes being made. Once I’m settled in, I might broach the topic, but for now, unless Microsoft swoops in next year and offers Dorian and I piles of money to merge their crappy RDP client (with a stable backend) with CoRD’s awesomeness (sans the crappy backend), or a new developer or two sneaks in and begins contributing, the future of CoRD is murky at best.

0.6

The parameters for the next iteration of CoRD continue to change for me. At one point, we had agreed that 0.6 was to focus on Groups. The plan, in its rarest form, was that we’d snap out the TableView, and snap in an OutlineView, and roll out 0.6.

Things are never that easy.

Currently, each server is stored in its own .rdp file, which are all lumped together in some forgotten directory (~/Library/Application Support/CoRD/Servers). Once we add groups, how we handle session storage becomes important all of a sudden. Originally we wanted to continue the file-based approach, and make a 1-to-1 relationship between groups and folders inside our Servers directory. With that tactic, in addition to handling the groups, we also have to obey and handle folder creation, deletion, renaming, etc,. inside of CoRD. I don’t really want to have to build a file browser (essentially) into it. Cocoa’s interfaces for file and folder manipulation aren’t terrible, but they are not lovely either.

The solution to this problem is easy enough, we dump everything into a plist (the recursive methods for that took me all of 15 minutes to write and test once I had a class established to handle groups, and I’m a n00b still), and gin up some little import method to handle things when the new version is launched for the first time. Easy peasy. So now, we’re implementing an OutlineView, for the actual groups people see, and we’re shifting our storage paradigm.

But wait…now that we can group servers, we should be able to do bulk updates of the server info in groups.

And while we’re doing that, we should fix how we’re storing credentials, so that people with a 30 day password policy and 30 servers don’t have to manually update 900 passwords / year.

Also, with the current plan for groups, we’re losing the Connected/NotConnected paradigm of CoRD 0.3-0.5. Sessions will only show their state via their icon (and probably some other visual cue). This means sessions could be connected but hidden in a collapsed group and makes iterating through connected sessions unnecessarily complex. Perhaps we should re-evaluate how we handle that?

I could go on for a while with this kind of stuff, but I’ll stop there.

Rapidly, what seemed like a simple change, spins out of control into something far from simple, especially for an open source project. It could be argued that all of this is feature creep, but I don’t agree. This is a major overhaul of code, and should be treated as such. If we’re not overhauling the code specifically to implement these features, then how can we overhaul it, get it halfway there, release, and just expect everybody to be happy with it?

I know more than a few developers who’s mantra is “just ship it!” which is a mentality I can’t stand, especially on a project like this, where A) many people LIVE in this app, and B) My name is in the code. I don’t want it to be a “work in progress, we’ll fix it in the next release” kind of overhaul. Mac users demand more, and Mac apps deserve more. Releasing half finished products is something I see too much of in the Windows world. I don’t want to be party to that kind of nonsense in the Mac world.

0.6++

The more I review crash reports, bug reports and feature requests, and the more I use CoRD day to day, the more I find I want to change. Full screen and the current inspector setup are our two single biggest causes of crashes (by far). Those need to be fixed soon. Most of the fullscreen code we’re going to rip out in favor of using the new fullscreen mode that all views get for free in 10.5 and up. I would like to somehow find a way to implement bindings, or at the very least significantly clean up the code that handles the inspector and manipulating sessions and try to isolate the potential for future crashes.

I want to eschew the drawer, and the rest of the current model really, and adopt more of a tabbed approach to the unified server window(s). The server list would/will remain completely independent, and pretty much exist purely to list servers, manipulate server data, and launch sessions. Individual sessions or groups of sessions live in Safari-esque windows with tabs, minimal bezel (read: no toolbars), and controls (disconnect, etc) for each session/group would be integrated into the perimeter to handle changing view modes (see the location of Safari’s new tab button), etc. The windows would be ginned up on the fly and tabs (active server connections) could be drag and dropped between them (just like Safari 4.x). Quick Connect would become a modal panel that would drop down overtop of whatever the active window was.

0.6--

The problem with this dream is two fold. First, that’s a shitload of work, and much of it is beyond my current abilities as a programmer (the latter part isn’t insurmountable, it just extends the development time significantly while I learn-as-i-go).

Second, I am becoming more and more disillusioned by the handicapped feeling I have because of rdesktop. The project is/has stagnated considerably, and attempts to fork or revive it have left me startlingly unimpressed. I think there’s a serious need for a code library, cross platform, and preferably BSD licensed (if it comes down to it, I could give a damn if it’s GPL, since CoRD is already GPL’d), to handle RDP. There are features in new versions of the RDP spec that CoRD can’t (and at this point could never) support due to its dependency on rdesktop, and some of those features are becoming essential to function in many environments (things like Network Level Authentication, SSL/TLS, stable printer support, etc).

Problems like the most recent cursor clusterfuck (that we’re still shoveling through fallout over), which caused cursors to render improperly on Windows 7 and Server 2008 R2 machines and the recent patch to rdesktop to support RDP’s reconnection feature via a local session “cookie” serve to highlight my frustration. Such changes proved challenging, and to some extent incredibly problematic, to integrate into CoRD due to rdesktop being built with a typical X environment in mind, and not more generic like a library would be.

So where are we?

The likelihood of an open source library being generated in the near future is very low. I would love to spearhead such an effort, but I have neither the time, nor the experience necessary for such an undertaking. I’m doing well to accomplish what I have thus far on CoRD. I’d settle for a couple of motivated guys who would want to help implement the RDP spec in Cocoa (which I think could be awesome as hell and fun to work on)

Most likely we’ll just shim in groups, and try to integrate as many of the necessary changes as we can into the codebase. At some point we’ll self-impose a deadline on ourselves, then we’ll back fill the remaining time with a couple of beta releases to identify any showstopping bugs before releasing 0.6 sometime this summer, around a year after posting 0.5. Our goal was to be on a much faster release cycle by now, but demands on my time and Dorian’s have caused a lapse in significant progress. Hopefully we can work to remedy that in the near future.

In 0.5.x news, we know there are several (rather large) bugs on 0.5.3, including but not limited to:

• Time Zone Sync doesn’t work
• Saved/Stored Passwords are broken for some sessions
• Cursor problems still exist

The top two are regressions, they worked in 0.5.2 but some of the rdesktop code we imported in broke them. The latter is something not many people will see, and we’re having a bear of a time troubleshooting it.

As always, thanks for all the support from our users, we appreciate the bug reports, and crash reports. Hopefully we’l be able to release 0.5.4 in the next month or so and fix several of the problems we introduced, as well as resolve some other stuff while we’re at it.

First!

Its been almost a year since I started working on the CoRD Project. In that time we’ve released 0.5, which was in “beta” for almost 18 months when I started tinkering with it in March of 2009. We’ve also released two minor updates that fixed major issues and added features, and are getting ready to release a third release (0.5.3) that will hopefully fix a few problems. Work on a 0.6 release has started, and rudimentary code has been put in place to allow groups. Going completely off of the amount of releases and code changes, it may seem like we’ve been resting on our laurels, but I wanted to point out the massive changes we’ve made on the backend in the past year that will help us accelerate releases and hopefully prevent another 18 month drought of updates and information.

Trac & Forums

This wasn’t an easy change though, as SourceForge could provide no migration of data from their Tracker to Trac. So I spent the better part of a month moving tickets by hand as I came across them, to the new system. We lost a lot of historical stuff in the forums, which sucks, but was a necessary evil. It was a ton of work to move this stuff, but in the end it turned out awesome and Dorian and I have been incredibly happy with it.

Crash Reporting

Prior to 0.5.2, Dorian had employed SmartCrashReports to some extent, but gathering and collating that data was incredibly difficult. Most crash reports we received either came in when a kind user attached them to a bug report they filed, or via email to one of us (mostly Dorian since his name and email are on the website ) In 0.5.2 we replaced SCR with UKCrashReporter and backended it with Dorian’s own CrashPool system. CrashPool, which will be going live soon for any interested developers, serves as a crash report aggregator, it handles sorting and grouping, searching, etc. Prior to 0.5.2, we both thought we were putting out a relatively stable app. Boy were we wrong!

We have a huge devoted group of awesome guys who are running the Nightly Builds (see CoRD’s preferences or this article) and reporting a ton of data back to us. And since 0.5.2 has been out we’ve gotten thousands of crash reports that we’re sorting through (it is really easy to spot trends; we know that guys who use Fullscreen heavily are seeing a metric shit load of crashes; and for some reason the inspector is causing some crashes that we haven’t been able to chase down (yet)). We definitely appreciate the guys (and gals) running the nightlies and providing us feedback and crash reports. Thanks!

Build & Deployment Infrastructure

This was all Dorian. He completely revamped his nightly build script and modified it to the point where we can release stuff practically on demand. The script will update the build the app, package it, upload it to the right places, update the appcasts, everything. He has a nightly task that runs and builds our nightlies, and by simply changing up the parameters we can dump out a release, either a beta or a full release, on demand. It is a truly awesome piece of code. Thus far he’s keeping is close-hold and not releasing it into the wild. But I think the eventual plan was to make it available, but it is his baby, a separate project in and of itself, so I can promise nothing, just give him credit where it is due.

VNC Requests

For those following CoRD on Twitter, I have wanted to make a tweet about this for some time now, but it is just too long of a thought for 140 characters. We see a lot of chatter, and the occasional feature request, about adding support for VNC connections into CoRD, theoretically making it a universal, kick ass, remote console tool. I share these thoughts. I would love to flip the magic switch, and allow CoRD to answer VNC requests. But I can’t, and even if I could, we’re not at a place where I would. There are many, many, many things I want to see in CoRD (including fixes for the aforementioned stability problems) before I see VNC support:

• Groups
• Better management of credentials
• Stable printer forwarding
• SSL/TLS support
• Smart Card support
• Autoreconnect support (rdesktop has this now, we have some code in place but no implementation yet)
• A complete rework of our drawing code to fix all the screen glitches people run into.

With just Dorian and I working on CoRD in our free time, we have to apply our time to where it makes the most sense and can do the most good. So just to put an end to any nonsense before it gets started, we’re not against being a good RDP/VNC app. But we want to be a robust, kickass RDP app first. In the mean time, there are plenty of really decent VNC apps out there.