I was at MIX this week speaking on a panel about web services. Obviously, the big announcements there were around Silverlight, so I’ve been getting emails asking what I think. Here you go, just a raw brain dump:
- No matter what happens, everyone wins. Competition is good for us. Adobe has urgency to improve Flash at a rapid rate, and Microsoft has urgency to catch up. Awesome for you and I – who cares who “wins” or if there even is a “winner”.
- Silverlight looks amazing. I want to consume Netflix movies using the Silverlight interface – it’s gorgeous and fast. But I don’t want to consume Netflix movies on my PC – I want to do it on my TV. That’s why I have an Xbox 360, AppleTV, and TiVo Series 3.
- I would like to develop for Silverlight just to see how neat it could be for our company, but there are two big problems:
- The installation process on Mac OS X is horrendous. And we have a lot of Mac OS X customers.
- Massive chicken-and-the-egg problem. My customers are not technical, and almost always just answer “No” to permission dialogs because they’ve been trained that “Yes” means “I’d love to be infected with a virus!”
- I have some fairly big performance complaints about Flash in some cases, so if Silverlight doesn’t suffer from the same issues, I’ll be pretty thrilled.
- Ray Ozzie & Co didn’t make nearly enough of a big deal about the fact that you can do this stuff in Python and Ruby in addition to C#. That’s huge and should have been the opening headline.
- Offering to host Silverlight videos for free (4GB) is a brilliant way to speed up adoption. Good move, MS!
So, anyway, there we go. I’m excited about it and skeptical about it at the same time. I think if the Mac installation process was a breeze AND I was able to create something really compelling, I’d be willing to show my customers how great it is. So the installation ball is in Microsoft’s court right now.
We’ll see what happens.
(Oh, and whoever organizes MIX next year, can we please please please have a real grid like every other conference? I missed great sessions because there was no grid)
As always (I should probably do a blog entry on this), anyone building something for our API or integrating an existing project gets a free lifetime Pro account at SmugMug. Just drop us a line.
And unlike some other sites online, we love it that you build commercial apps on our API. Go to town, make some money, change the world. We’ll help!
The subject says it all and I’m thrilled. Here’s some details:
- We’re an OpenID 1.1 Provider. Hundreds of thousands of SmugMug customers can now use their SmugMug homepage URL as their ID on sites all over the net.
- We don’t yet support Diffie-Hellman association, so if plaintext isn’t ok, you’ll have to fall back to dumb mode. Sorry about that. I’m hoping we can support DH soon, but I’m really waiting for Wez’s PHP patch to use OpenSSL’s functions. I may end up creating a custom build, we’ll see.
- We’re planning on consuming OpenID for photo comments and other things shortly.
- We probably have bugs. Sorry about that – let me know and we’ll get them fixed.
I’m a little worried with the direction OpenID 2.0 seems to be going – one of the great things about OpenID is how simple and easy-to-implement it is. I haven’t taken a good, close look yet, but the preliminary 2.0 spec seems to be complicating things a great deal. I see that as a Bad Thing(tm) but maybe I’m smoking crack.
The documentation for OpenID leaves a lot to be desired. Specifically, there’s no example messages, including sample values, for you to make sure your code is doing the right things. Luckily, the spec is so simple that some trial-and-error takes care of things, and someone has written a great narrative overview of the implementation. I will put up an OpenID page on our wiki that includes example requests and responses, including secret keys, so anyone else implementing this from scratch has some values to work from.
LiveJournal (and thus, Brad’s CPAN module used by lots of other services) seems to have some bug in it where it doesn’t like OpenID server URLs without a trailing “/”. It returns a useless (to me?) error message: “naive_verify_failed_network” which meant I spent hours and hours of time going over my code with a fine-toothed comb. Finally, out of ideas, I made a 1 character change to my HTML and everything magically worked. I don’t understand why, since the docs don’t state this, and Vox seems to have an openid.server without a trailing /, but oh well. It fixed my problem. Hopefully this will help someone else figure out what that message might mean.
There are clearly still issues around OpenID, such as what happens years from now when your OpenID identities are lingering out there long after you’ve closed the account from which the ID was provided? Someone else may even own or use that old URL if it’s been repurposed. But there seem to be smart people thinking about the problem, so hopefully everyone will figure it out without bloating it or making it unusuable.
I think OpenID is huge, and I’m glad we’re able to move the ball up the field a few more inches.
I’ve been hounding GreenJimmy, our resident Web SuperHero, to write up our approach to solving the Browser History problem when using AJAX apps. I wrote in broad terms about our solution (and how it worked on Safari, the tough one, in addition to Internet Explorer, Firefox, etc), and promised that Jimmy would update his blog with a detailed explanation.
That was exactly a month ago, and Jimmy has written exactly nothing. I guess I need to employ more Lex Luthor management techniques, because clearly I’m sucking in the boss category.
Luckily, our friends over at Yahoo have a new Browser History Manager in the latest YUI release, and it does the same thing we did in the same way. Best part? They actually wrote up how they did it so the rest of the world can use it. So if you’re curious as to how to get Safari to behave with proper history, including full back/forward button support, go read up.
Many apologies for everyone waiting around (and emailing me) for our solution. Many thanks to Yahoo for stepping up to the plate and sharing.
Today, the YUI blog mentions they’ve released a great new version. As you probably know, we’re a huge fan of YUI – we couldn’t have done our fantastic new UI without it. We’ll be at the YUI party this week, celebrating with everyone else.
When talking about the new Browser History Manager, they mention that “No one, as far as we know, has resolved the technical issues in a satisfactory way across the A-Grade.” Alas, that’s just not true – SmugMug has solved this technical issue, and we did it first. What’s more, the YUI team knows about it – we had lunch with them and told them exactly how we did it. Their Safari implementation is exactly the same as what we did and explained. We even offered to give our code back to them under a BSD license so they wouldn’t have to duplicate our work.
It looks like they missed one technical detail of our implementation, though. Safari has an issue with “permathrobber” (basically, the Safari throbber never stops throbbing) which we managed to solve.
Note that I’m not upset that they have a great Browser History Manager – far from it. I just wish they’d give us a little credit where credit is due, given that we pimp YUI any chance we get for them.
We built it first, they know it, and sharing the love is the right thing to do.
UPDATE: Just called Yahoo and the love is still flowing. Turns out the two guys who wrote the Browser History Manager are new to the team, weren’t at our lunch, and had no idea what we were doing. Great minds think alike. And Yahoo can’t accept our code currently, even under a BSD license, but they’re working hard at getting that changed. Sounds like an internal big-company roadblock.
Yahoo! Hack Day
SmugMug was in the house at Hack Day 2006, and we had a great time! Many thanks to Yahoo for putting on such a great event – we learned a lot about Yahoo technologies and put together a great demo. Anytime they want to throw another one, we’ll be there. Fantastic group of people over at Yahoo.
Best part about it is that our demo will shortly be a shipping product our customers will love and that’ll generate extra revenue for our company. Oh, and BigWebGuy got his official hazing there at Hack Day – he coded for 36 hours straight (no sleep!) his first week on the job even though he was sick! Welcome to the family, Lee!
The Sun T1000 is very much still on our radar. I don’t want to do an in-depth update until we’re absolutely sure about what’s going on, but here’s a short summary of where we are.
I spent 5 hours over at Sun a few days after our initial results were posted with some very intelligent people. They were as perplexed at the results as I was, and were determined to get to the bottom of it. The good news is we now have a T1000 running Solaris side-by-side with a T1000 running Ubuntu which is side-by-side with our dual dual-core Opteron running Red Hat. The bad news is the Sun guys weren’t able to coax any more performance (yet!) out of the T1000.
We have a theory that we might be saturating the GigE port with raw # of interrupts per second, so it’s getting throttled there and starving the CPUs. So we have a gameplan for what to attack next – I’ve just been too swamped to deal with it for the last few weeks. We’ll get to it, though, I promise and I’ll share all the details.
I still haven’t posted the in-depth technical details and code samples I promised about our use of Amazon S3, but fear not – I’m actively working on it and will post it as soon as it’s done.
Just wanted you to know I hadn’t forgotten about you.
Incidentally, Jeremy Zawodny is playing around with using it for his personal backup storage. Sounds sweet!
I’ve only spent a few minutes playing with it, but it’s really good so far. They did a nice job with the interface, especially “clustering” photos together as you zoom in and out.
I’m excited about this. Our customers have been enjoying geotagging support for more than a year (see Tim’s post about it), and I know Zooomr’s had good support for awhile, too. But Flickr has lot more market share, mind share, and PR leverage than the rest of us do, so hopefully this will get camera manufacturers to get on the ball and make this a standard checklist feature. Let’s hope so.