Cracking Eggs

If you follow our UserVoice forums, you might know that my latest directive, by popular vote, is to add some kind of collaboration to Mockingbird.  Though I haven't really decided on how this is going to look, I couldn't help but check out the variety of real-time-push-comet-right-here-right-now-web frameworks. Since I knew nothing (and now know next to nothing) about what's out there, the first step was, well, to see what's out there.  I ended up deciding to play around with Node.js + WebSockets (specifically, using Socket.IO - a nifty little framework on top of Node.js that will use WebSockets when possible and fall back to other Comet methods otherwise).

Instead of making the usual sample chat client, I decided to try to make a very simple collaborative drawing application by integrating Socket.IO with Cappuccino so that I can also try to play around with various ways to synchronize user data (see my Hacker News thread about it).  I haven't actually put in any kind of sophisticated data synchronization yet, but the code for what I do have so far is here: http://github.com/saikat/drawtogether.

And here it is in action:

Check out the README at the Github repo to get it up and running.  The code itself is fairly simple.  All the backend work is in server.js, and in there, the actual interesting parts that are doing anything other than serving static files start with the line "var listener = io.listen...".  On the client-side, I made a very simple Objective-J class that wraps the Socket.IO client called SCSocket (located in client/SCSocket.j).  It's up to you to simply set a delegate on this class and implement any of four methods (see setDelegate: on SCSocket) to handle notifications from the backend.  To send notifications to the Node server, simple call [[SCSocket sharedSocket] sendMessage:].

We just deployed a new version of Mockingbird that is officially running SCAuth for all of its authentication needs.

Which leads to the obvious question - what exactly is SCAuth and why would you care about it?  

If, like me, you have an application running on Cappuccino that requires users to login, you probably have a bunch of code that deals with keeping track of the users' session data, keeping it in sync with the backend, and showing users a login dialog at the right times.  There are a couple of not-so-well-known classes/hooks in Cappuccino that make this easier for you (I'm looking at you, CPUserSessionManager and setClassDelegate on CPURLConnection), but it wasn't quite enough for me, so I made SCAuth on top of it to do a bit more. SCAuth comes with SCUserSessionManager which subclasses CPUserSessionManager to make the class a bit more robust (letting you do things like logout and sync your session data).  Eventually, I'd like to make SCAuth handle all kinds of session data depending on what login provider is being used (for example, if your app uses Facebook Connect to login, there are probably facebook connect-y things you want to access about the user from your Cappuccino application).  This should be pretty easily possible by just switching out the login provider that SCAuth uses.

SCAuth also uses setClassDelegate on CPURLConnection to deal with making your users login whenever they do something that requires them to log in.  It uses the login provider that is set on the SCUserSessionManager to deal with logging the user in.  By default, this login provider is a login dialog that comes with SCAuth, but it's pretty easy to make this login provider whatever you want.  

After refactoring Mockingbird to abstract out all this authentication nonsense, I cut down quite a few lines of code, so hopefully someone else will also find this useful (or, if not, make suggestions for how it can be more useful).  You can read the README at the github page for more details.  Oh, and there is an example.