Saturday, June 28, 2008

Flagstaff Amphitheater == Montalvo Amphitheater?

Years ago I was lucky enough to see a show (Amiee Mann) at the Montalvo Amphitheater in Saratoga, CA. The small outdoor venue was ideal (as was the music). Not having ready geographic access to it anymore is a bummer. I wonder if Boulder, in conjunction with Boulder Theater and/or BMOCA, could support a similar Arts/Theater/Concert Series via the Flagstaff Amphitheater? Bus people up from downtown, drop them off, then pick them up after the show. I guess Chautauqua's Concert Series kinda does what I want, but the venue, while neat, is pretty poor in terms of intimacy and comfort.

Thursday, June 12, 2008

Clouds and Sympatric Speciation

I just canceled Gnip's account with its traditional hosting provider. We had a good experience with them, but we moved our stuff to the AWS/Ec2 recently so they became obsolete for us. I also just received the following email from our account representative there (a good guy).

"Hi Jud. I'd like to keep you as a customer. I think that PROVIDER-NAME has a good reputation for working hard to provide good service. We have some great hardware and data center, too. I am prepared to create a web-based API for you to create, resize, shutdown, reinstall VPSs. You'd be able to do that on host servers you own (most cost effective) or on any of our regular shared host servers (which would give you the instant scalability you need). Plus with our setup each server instance would retain its IP address between restarts, and you'd have a file system that remained between reboots (and did not require re-setup), plus you'd still have the option of using S3 for shared data or large data sets if you needed it. What would it take to keep you as a customer? We can implement most things for you and hopefully we can save you a lot of time, hassle and effort changing hosting providers."

The email struck me as a form of sympatric speciation. Sympatric speciation is an form of evolution in which two things from the same pool evolve in different directions (for a variety of reasons). All the hardware on Amazon's racks is the same as that in my previous hosted provider's racks, yet, Amazon just sympatricly speciated away from its genetic bretheren. If evolution has taught us anything, it's that the "other species" does not go down without a fight. I'm reminded of some lyrics by Dave Matthew's "Don't Drink the Water;" "Whats this you say, you feel a right to remain? Then stay and I will bury you."

Tuesday, June 10, 2008

Calendar Dancing

Every few months I sit down and try to mash all my calendars together, in hopes that the various calendar services I use have fixed all their bugs. You'd think that in today's world of well known ical formats, ics subscriptions, and new browser protocol handlers, webcal://, that things would work well together.

The energy is definitely here. Dozens of products and services offer calendar "imports" or "subscriptions" which purport to import calendar entries. Some do this well, but most either don't work with arbitrary services (e.g. they only work with a select set of other calendar feeds), or are severely buggy. I'll keep dreaming of seamless integration and mashups, but for now, here are some prohibitive issues that consistently come up.

HTTP Basic AUTH and Subscription access control - If you've been anywhere near me over the past few months, you'll know my stance on HTTP Basic AUTH. In short, it's woefully underused. An old colleague has a great post that personifies my perspective. If more software supported HTTP Basic AUTH it would be the perfect way to support access control to calendar subscriptions; something that effectively doesn't exist today. Protocol level auth is often the only way to resolve this kind of mashing up.

Google Calendar - oddly the worst at importing/exporting. I'd expect a company known for parsing/derivation to have imports nailed; hardly!
  • webcal vs. http schemes - the transport is identical, please just treat the URLs the same.
  • get your own imports to work. I can't even import a Google Groups calendar into a Google domain hosted calendar.
  • importing 30boxes shared calendars via tags doesn't work. the same calendars imported into Apple iCal work just fine.
30Boxes - my personal favorite.
  • again, webcal vs. http schemes - they're the same thing folks... allow both and determine what format you're dealing with in the HTTP response that comes back.
  • Many ics subscriptions are PRIVATE and use the VFREEBUSY blocks for entries. Please support these so I can import more content into 30boxes.
Dopplr - great tool for communicating overlapping travel schedules
  • I've noticed webcal vs. http scheme madness here and there, but overall fabulous import facilities.
Apple iCal - great, except it's client-side, and I need hosted calendars for arbitrary endpoint/location access.
  • the gold standard in importing and exporting. if it doesn't work here, it won't work elsewhere. I wish other apps worked this well.

Wednesday, June 4, 2008

You've Got My Vote, Go Get Someone Else's!

It looks like the Democratic party might have what it considers a reason to select a candidate. Boy oh boy that would be nice considering all the intra-party bickering, and money wasting, that has been going on for nearly a year, while McCain has been lounging and resting as the Republican's nominee. If you didn't catch his appearance in a recent Saturday Night Live "Weekend Update" bit, check it out, it's spot on!

I'm embarrassed to be lefty after this mess.

Living in a "liberal" town, Boulder, CO, I'd ask that we, as Dems, not spend the next year promoting our candidates and party in our own backyard. Guess what, I'm already sold on our candidate, and I don't need to see party volunteers pumping up me and my fellow Dems in the area. As a party we need to spread the word in areas that aren't predominately Democratic. We need to convince folks who are "on the fence" to vote Democratic, not eachother.

I'm not looking forward to all the "Obama!" PR that'll be all over my town for the next 12 months+. It'll be yet another tremendous waste of spirit, passion, & money.

Let's move on.

Aside: I picked a Russian propaganda poster ("Don't blab!") for this post as the old mother Russia had propaganda nailed. Russian propaganda posters are fascinating to me, as they illustrate the power of communication, and Russia's effectiveness, at convincing their populous of a rather bizarre set of beliefs and fears.

Monday, June 2, 2008

Sockets, HTTP, XMPP, and Leap Frog

My efforts at Gnip have caused me to re-consider a few things on the protocol front. Growing up at Netscape in the "netlib" group (really just 3 of us) gave me an interesting perspective on "internet protocols." Over the years it became apparent that HTTP was the end all. Much like twisted-pair copper wiring pervades "connectivity" into homes in the US, HTTP will be around "forever." However, I'm realizing that, also much like twisted-pair, HTTP is becoming a dinosaur in today's modern network infrastructure.

Connection throughput, latency, and reliability is amazingly good in today's tubes. We had a room full of win 16 installations with over a dozen different TCP stacks (winsocks) installed to test a zillion different connection scenarios (yes... socket->open(); "did it work?"). Today, the socket is an assumed reliable, and consistent thing. This is all to say that stateless transport protocols, like HTTP, were fundamental early on. I felt lucky that a response would come back from the same IP address a request was sent to for crying out loud. Binding any state to that connection was something only a company with the capital resources available like AOL/Prodigy/IBM/Compuserve, could pull off. AOL invested hundreds of millions of dollars building out their backend. They did deals with modem manufacturers to ensure 300 baud connection purity and to minimize drops. Madness!

Protocol Leap Frog
Even 15 years ago the stateless (HTTP/open internet) vs. stateful (FDO/SAPI/AOL) connection war was raging. AOL lost obviously, but they made billions with a connection that rarely broke between a machine in your house, and a server in a data center (over twisted-pair copper wiring); the amount of state moving over that connection literally blurred the line between where the app began, and ended (is AOL a client-side app or server-side?).

The battle is back in my mind. XMPP is a relatively defined protocol (sure HTTP is spec'd to death, but every client and server does things differently, sometimes woefully differently) that has both stateless (connection up/down) models, and stateful (connection always up) models. The latter is what can get really interesting given the new network topology and quality we live with today. An open version of AOL's transport layer basics if you will. Feels powerful.

With today's connection characteristics, I wonder if HTTP would have been the weapon of choice 15-20 years ago? I doubt it.

Many hurdles remain however. The entire network has been built out with HTTP connection assumptions. The way ports are monitored/firewalled inhibit any new connection types from taking hold. App developers think in terms of AJaX & *HttpRequest(), not publish and subscribe frameworks. XMPP is far from ubiquitous, and even if it's lucky, might not even broach HTTP's market penetration radar, but it deserves some time on the field.

Change like this doesn't come quick, and it doesn't come easy.