Why is IFBIN 2.0 using Apollo?
DIGG IT!
8
Comments
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 :)
Is there not an option to created a limited functionality version online only? This way those who do not instantly "get it" can check it out and see why it's worth downloading Apollo and the full blown IFBIN2.0 experience.
There will be a view-only version of IFBIN 2.0 app online.
Here is the demo UI build we put together for IFBIN 1.0 running online.
http://www.ifbin.com/flex/
Ted :)
Partially to be a devil's advocate here, let me suggest a reason NOT to use apollo is that it's not as "open" or universal as most web based technologies. Not saying it won't be soon... but that's certainly a reason I'd consider. Say it doesn't take off and it becomes another Central 1.5. I doubt that'll happen though.
Having said this, the options to have the persistence and such outside of Apollo makes me think any other solution would be too customized and non-standard... so, Apollo is actually more standard than say, a swf-to-exe projector.
Finally, what's the security model in Apollo? Is that specified yet? It's just that if you want to copy files... certainly upload... the will be some issues no?
Thanks!
Central was a "developer release", Apollo is not.
Additionally Adobe is putting a lot of weight behind Apollo. There are many internal apps in development that will leverage Apollo and there are many high profile companies developing applications with it.
Apollo is a closed alpha right now but there is a public beta before Q2 2007. The key is Apollo costs nothing, it is another free runtime from Adobe like Reader and Flash Player before it. The difference is this runtime is for making desktop applications.
A couple of facts:
1. Public beta of Apollo before Q2 2007.
2. Apollo is free. Free to build, deploy, use for any purpose.
The security model for Apollo is in development now. Saying anything about it would be premature. Desktop software can read and write without restriction to the file system, why shouldn't Apollo?
I have been using Apollo since M0 internally and it rocks. Each release is a major jump in functionality towards the final builds.
Apollo is very real and soon you will get to see it and IFBIN 2.0 first hand.
Ted :)
(Phillip again--dunno how to log in on this computer)
I hear you about Apollo's momentum and likely future--but it's still speculation. When I pitch it to clients they bring up the same comments I made.
As it's in alpha it's all sort of premature really no? Even saying that it will be free--I mean, I believe you but it's not out let alone really spelled out yet.
Regarding desktop apps having full access... I assume your question is intended to get a response. I'm not so sure the answer (to your question) is so obvious--if it was, the security model would be disclosed--where back at MAX it was still clear that it was undecided yet. In my view, I like making apps with full access. However, I'm not sure what I want, expect, or would suggest to Adobe on this matter. I think the potential to backfire is there. Here's my ideal view:
--all apps have the potential to do anything, but every operation is clearly displayed to the user with options to "allow".
--all my "allow/don't allow" settings are easy to come back and review. Something like how Zone Alarm works.
--you all figure out a way to first NOT scare regular users with the initial install of Apollo but balance that with clear disclosure to people like my mom when it comes to what vunerabilities they're opening by giving an app their trust.
It's a tough balance if you ask me. But, it's one that must be done with full transparency or else someone will rightfully point out that Apollo generally is risky... or worse, that someone's virus that happen to use Apollo as the vehicle is not Adobe's fault.
Good luck, I want it to succeed because I want to build more cool apps!
I can definitely see the value of making the upload interface an RIA, perhaps even an offline one: the persistence, the immediate feedback, the desktop integration... But I most definitely think that the viewer and downloading could just as well have been done in HTML. Don't get me wrong, I hate HTML as much as the next guy, but it does have its advantages. Instead of having a built-in search feature, I could just use Firefox's Ctrl+F. I could bookmark a page for a download if I see something that I don't need now, but I might later. The content would be easily indexed by Google.
Just so we're clear, I'm not bashing Apollo or Flex 2 or anything. I've already created the amfphp 2 service browser in Flex 2, and I am thinking of wrapping it in Apollo when it is going to go beta. In that case, I think Flex 2 is a perfect fit since we are really dealing with an application metaphor: screens, controls, testing, saving. But I wonder how much of IFBIN 2.0 fits in an app metaphor: searching, downloading, bookmarking, it feels like it's a better fit for a hypertext metaphor. Nothing wrong with using Flex, but it's better for some things, HTML is better for others; the question is about choosing the right tool for the right job.
In the case of IFBIN 1.0, it felt like the choice of a downloaded app was triggered by licensing concerns. Since IFBIN 2.0 will be open, that concern becomes null.
I think all your points are valid if you take a look at the uploading part of the app. But as far as the browsing and downloading part goes, well, let's see:
1. Browsers have built-in functions for indexing bookmarks, such as Firefox's Ctrl+B. Del.icio.us is available if you want more power. Although the IFBIN icon might take up more screen real estate, it also doesn't fit into my usual workflow, which is why I might not end up using it as much. It won't show up when I search for an example in Google, for example.
2. Downloading is a 1-click process in Firefox. Furthermore, it comes with a built-in download manager if I want to redownload a broken file. The ZIP format has a CRC32 check, and Windows will notify you if the archive is invalid.
3. Users are going to have to download a large file before starting to browse. They would have to browse dozens of HTML pages to make up for that bandwidth.
4. A valid point.
5. Mashups and syndication are buzzwords these days. I think you're stretching it a bit here.
6. A valid point, although I usually keep a copy of the zip file when I download it if I need to revert.
7. You know as well as I do that you wouldn't have 1000's of HTML pages. You would have used a framework like TurboGears that would have made changes across all pages trivial.
8. A valid point.
9. Lynx runs in DOS ;)
10. I already have several browsers installed on my computer.
Again, Ted, not bashing, just reminding you why I and some of the other IFBIN authors had major concerns about the download, or more accurately, about the fact that the website wasn't enticing users to download the product. If you read the feedback in "Blunt survey for lurking issues #2" on the IFBIN list, you will see that a lot of author's (me, Jesse, Tink, etc.) top concern were that the website wasn't doing its job. I just don't want to see IFBIN 2.0 fail for that exact reason.
I agree that the public site needs to be searchable and bookmarkable. We should make that happen.
Ted :)
Ted, just wondering, will the actual IFBIN Apollo client be open source (I know the content will)?