peelman.us

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.