January 01, 2006

Don't Ever Underestimate The Power Of Simplicity

[UPDATE: I've recently added a new server to the system to accomodate for additional traffic for the nuxle.us project. In doing so there will be a potential period where you will be directed to a GoDaddy default page while zone file updates are transitioned. It shouldn't last very long at all, but if you do have problems I've added a 'temp' sub-domain which should help bypass any issue temporarily. You should be able to access that now (if necessary) at http://temp.nuxle.us. My apologies in advance for any confusion.]

ongoing ? Protocol Day One

A recent Tim Bray post brings the year into perspective using a retrospective summary. Setting aside the fact that I think this is a fantastic idea (and if Kurt's up for it would be GREAT subject material for eXplorations[feed]) there was this entry for September:

September: Those who know what curl is are probably snickering now

A few days ago I made mention of the nuxle.us project. The nuxle.us project is about two things: One that's obvious (XML Messaging) the other not-so-obvious (Identity/Security). While after speaking with Eve Maler on the topic, I came to the conclusion that "Wow! SAML is REALLY cool!" and "This fits PERFECT into what the nuxle.us project is all about" which is:

Secured End-to-End XML Messaging [UPDATE: from an "Atomic" standpoint, defining Atomic in this case to mean a single node/unit on the internet whether that be your own personal machine, a server, etc...]

The simplified algorithm looks something like:

  * Recieve an XML Message.
  * Determine how to properly handle
      * either pass it to a system process registered to handle this message type,
         * return either an error code or result from this system process to then return to the message to the original sender/requestor
      * return a message suggesting that more things need to be known before the message can be accepted.
  * sever all ties. for now ;)

So what does this have to do with curl?

Good question. The September link from the above quote contains the following text:

The only server on the air was from Dave Johnson. We got two different clients to talk to it; one was a Big Secret Project from a Big Famous Company based on all sorts of slick infrastructure. Mine was curl. I managed to introspect the server, list the entries, create a new entry, update it, and delete it. I screwed up the messaging a few times, and Dave’s server only blew chunks about half of them. Those who know what curl is are probably snickering now. But I think the fact that you can debug a nontrivial application with curl -X -i -d -H is a significant weapon in the quiver of RESTafarians. Let’s see ya do that with your SOAP + WSDL + WS-Policy + WS-Addressing + WS-MetadataExchange + WS-ReliableMessaging app. Actually, the big take-away isn’t that, it’s that the Atom protocol is simple and easy to implement and robust.

Right after this is the following statement:

The world needs something like this.

While I can't say for sure if with 'this' Tim was refering to the Atom Publishing Protocol or the creation of a utility that is APP-aware, suffice it to say, nuxle.us is (based on and older version of APP) and will be (based on the final release of the APP specification) compliant in every way, shape, and form with the APP specification, exposing this functionality via a simple interface that, because of curl/libcurl [1], will be easily accessible to your language of choice.

The only unknown at this stage is how well SAML fits into all of this. Eve has been good enough to supply me with a TON of fantastic information of which I have been pouring through as time permits. I've been holding off a bit from this as I have wanted to gain Uche's insight on things as I know his experience in this area (Security/Identity via SAML) is quite a bit greater than mine (actually, thats an assumption, but I think a safe one when you realize that what I know (or more accurately, knew. I know more now, but still have LOTS of learning to do) about SAML is basically nothing and as such want to chat with both Uche and Eve a bit and see where they feel 'curl' and SAML can compliment each other and where they can not (if that happens to be the case).

I have noticed that Uche is back up and running on IM, but given the fact that he recently returned (yesterday if I'm not mistaken) from a trip to Nigeria with his family, coupled with the fact that its New Years Eve, my guess is that holding things off for a day before pestering him for advice is a pretty good idea. While I do plan to send him an email on the subject later this evening, I also plan to make sure it is labeled [FOR WHEN YOU HAVE TIME] at the top. While there will be plenty of information available regarding this, and other projects, at some point tommorrow (Jan:One based on US Mountain Standard Time) I'm more concerned with doing this right the first time than I am concerned with pushing this out the door before its ready.

With that said, what you will find tommorrow will be forums, a Trac-based Project Management Interface/Wiki/SVN Repository viewer, a general FAQ, and a call-for-participation with a very detailed time-line as to when each phase of this project will be closed-for-comments, implemented, and then reopened for further testing, comments, and community participation. While I'm not opposed to making changes to the schedule, the reasons for wanting to make these changes need to be pretty strong, as I have no desire, plan, nor intention to let the pace of this project be dictated by anything other than good, solid, well argued reasons as to why the need to hold things back exists.

One other thing worth noting:

I made mention in the above linked post of a connection to Jabber. Jabber is a FANTASTIC real time XML messaging protocol with TONS and TONS and TONS of supporting server and client projects. nuxle.us will have the ability to both plug into an existing Jabber server implementation such as Jive Software's Wildfire (formerly Jive Messenger) as well as implement its own server via the various available code libraries. How this will all be implemented is part of what I plan to ask for community participation with. I have my own ideas, but I come from a Windows heavy world, and Jabber/XMPP comes from a Linux/Unix heavy support infrastructure. As such, I will be asking for and listening to what these communities, as well as the Windows/.NET/Mono communities have to say on the matter. This project isn't about living in a bubble. It's about secured XML messaging and XML is all about interop. Well, interop, and the ability to build upon a reliable data format in which we can build tools and processors against and expect that we can use these same XML-based data files on any platform, no matter what, using any spec-compliant XML parser and processor we want, no matter what. But then again, that pretty much defines interop [UPDATE: or at very least encapsulates the general ideas behind interop].

Bubbles and interop don't mesh well. ;)

OK, keep your eyes peeled and your ear to the ground and have a Happy New Year everyone! Enjoy your night, cuz tomorrow?

Tomorrow's the beginning of a whole new year era. ;) :D

---
[1] : for those unaware, curl is a much beloved and heavily used utility that covers the gamut of internet-based protocols such HTTP*, FTP*, GOPHER, TELNET, DICT, FILE and LDAP, and does so with grace, and ease, and simplicity. The fact that its accessible via more language wrappers than you probably realized even existed (speaking to the number of languages that expose curl functionality through libcurl, the API library for invoking curl-based functions from within the application domain. see: left-hand side of libcurl front page) coupled with the fact that its an open source project maintained by (I'm guessing) thousands of active and enthusiastic loyalists suggests this is a project that if you don't already, you really need to learn about and start using.