Why is IFBIN 2.0 using Apollo?
DIGG IT!
Published
Wednesday, December 27, 2006
at
10:16 AM
.
Patrick Mineault asked why I was writing IFBIN in Apollo and not as a website. There are many reasons but my employer is NOT one of them. Truth be told the original IFBIN plan was to ship on Central 1.5 but given its "developer release" status, things didn't happen there. Lets dive into the issue:1. Installed vs URL - There is a lot of value in being installed on the desktop. URLS are hard to remember for regular folks (even advanced folks). Plus with over 200 bookmarks, I struggle to locate a site I found before. Being an icon on the desktop is more valuable than being a website. Many key services will move towards Apollo to enjoy this exclusivity. Plus as Apollo has a browser you can control the experience, yet integrate easily with all things web.
2. Browser is a tiny sandbox - The web browser is a very restrictive sandbox. Why cater to incompatible browser quirks, when your app can become the browser? Apollo lets you control the entire user experience and deliver functionality that websites cannot.
2. FileIO - IFBIN 1.0 made installing secure file systems as easy as 1 click cross platform. If we used a browser, here are the features that would go away:
a. 1-Click - Make installing files easy, do not make me think! I want IFBIN to work for everyone, not a limited market who knows SVN/CVS/ZIP.
b. File Verification - IFBIN can verify if every byte in a file is authentic and genuine. If the file contents have been tampered with, the file will not install. This protects end users and is especially valuable when end users are uploading content into IFBIN.
c. IFBIN Secret Feature #1 - There is a killer feature that can only be delivered leveraging FileIO in Apollo. It makes the web more readable and writable. :)
3. Scalability - With UI and logic moving into Apollo on the client side, the server side gets simpler and more scalable. Having to send the presentation layer over and over and over and over is silly. It is a waste of bandwidth and server resources that are better handled within the client. I am concerned about scalability with IFBIN server-side and leveraging an intelligent client makes things much simpler, more scalable, and more configurable.
Take the file upload functionality: The user selects a directory to upload, enters meta-data about the file system, and the IFBIN 2.0 Apollo app prepares a binary file to upload that is highly optimized. The file is uploaded to the server where the file is processed into the backend including source search indexing, category publishing, tag processing, and updating a developer profile. The file is then one approval away from being published. Scalability here also applies to my time, I do not have tons of time to manage IFBIN, so the system needs to be 99.99% automated and distributed.
4. Context - IFBIN 2.0 knows what the user has installed, searched, and viewed. The service can notify the user about new versions, similar content, and search for similar files (same author, same class, etc).
5. Partnership - IFBIN is going to work on a partner model to monetize operations. Partnership on the web today is distractive in nature and content sites typically must hand users to another site. As Apollo contains a browser, IFBIN 2.0 can provide a more controlled partnership model in context. Think sponsored bookstore within IFBIN, category sponsorship, and special offers in context with the service.
6. Offline - IFBIN installation files are cached so a user can re-install without a network connection. Typically with examples developer tinker with code to see what will happen. This type of discovery is at the heart of IFBIN in terms of value. If you want to get things back to the starting state, you are 1 click away even if your are on an airplane.
7. 1000's of HTML pages vs. 1 SWF + API - I think that SWF + API is the right model. It allows me to rapidly change the entire application at once without modifying the server at all. This is 1000 times more scalable than most web production. Also you gain the benefits of having an API for 3rd party integration/syndication without doing anything special. I know many would disagree with me here, but that is my opinion. Leveraging that same model in Apollo is the right call.
8. Persistence - Apollo can persist and cache data on the client side. With client persistence the server-side becomes even simpler. Sessions in Apollo can maintain state far longer than the browser. With IFBIN 2.0, why would you need to login or logout? When client storage becomes rich, many of the key pillars of web technology fall apart. My choice in leveraging TurboGears/CherryPy is the low level control over HTTP, productive development of the XML API, and leveraging ORM mapping in SQLObject. Cookies, Sessions, HTML, Javascript, CSS, AJAX will go unused in IFBIN 2.0 because I am not sending the presentation layer over HTTP and I can persist client data intelligently.
9. Compatibility - Apollo apps run compatibly cross platform. In choosing Apollo, I assure support on Windows, OSX, Linux from the same file! In choosing Apollo I choose the widest possible market for IFBIN. IFBIN 2.0 can provide a dramatically better experience without limiting customer base.
10. Installation - The install process for IFBIN 2.0 and the Apollo Runtime is 1 click. It is so easy, that both my mother and father can do it. I typically rate them a 1 in 10 on a technical scale. Actually installing IFBIN 1.1 today is much harder.
Patrick, I guess in a way I am biased towards this model of development given my experience and job at Adobe. But then again I was biased long before working at Adobe and I know this is the right model to make IFBIN a success. The failure of IFBIN was more personal/business than technical, no need to rehash that uglyness yet again.
Here are some key milestones for IFBIN 1.0:
46,000 installations with a marketing budget of $0.
Average 3,500 unique users in Dec 2006 and rising steadily.
700+ of the best code examples ever assembled for Flash/Flex.
IFBIN royalties paid Darron's rent by majority 3 months in a row.
I worked with some of the best developers I have ever met.
IFBIN was licensed for use at the MIT Media Lab.
IFBIN acquired 150 customers with whom I am forever in debt. IFBIN 2.0 is dedicated to them. Each customer will be listed in the IFBIN credits.
Zero server downtime, thanks FreeBSD!!
Fun, Simple, and Easy to use.
That is success in my book. It wasn't financial success but IFBIN was right on many levels. IFBIN 1.0 remains technologically sound, runs cross-platform, and works 100% today. I have a lot of work to do to best IFBIN 1.0 in terms of stability and performance.
Honestly, if I were to build IFBIN from scratch using any technology at my disposal, I would go this exact route. Cross platform distributed applications are the future of the Internet and choosing Apollo gives me a much deeper technology stack than the browser provides. Delivering a dramatically better application experience cross-platform is the bread and butter of Adobe Apollo.
I am sure there are new lessons to learn in the development of IFBIN 2.0. Software development is a journey and the lessons along the way are the fun part.
Lead with Grenades!
Ted :)