Monday, November 17, 2008
How Flash Can Integrate With The Open Web
[Big giant usual disclaimer: These are my own thoughts and opinions and not those of my employer]
Dion just put up a great post on how Adobe can join the Open Web by open sourcing Flash. I agree with him, and just wanted to add to the conversation a bit.
I've actually been turning this idea around in my head as well. It might surprise you since I'm an Open Web Advocate, but I like Flash. I've always tried to be non-ideological in my work. Flash has done good things and created a great deal of innovation. Adobe (and Macromedia before it) has always been good about evolving Flash forward, including making ActionScript more like JavaScript, embracing markup language development, open sourcing Flex, and more. I'd like to see Flash continue to evolve into being a core part of the Open Web. This would be good for Flash and good for the Open Web.
As Dion points out open sourcing Flash is one big part of making this happen, but another huge aspect would be to have Flash and Flex integrate better into the web stack and be less of a 'black box' on the screen.
Here are some suggested ways to make Flash & Flex more a part of the Open Web -- these are just suggestions. The important point is to integrate Flash and Flex more deeply into how the Open Web works:
Directly push Flex and ActionScript to the browser and Embrace View Source
Right now Flex and Flash work by compiling everything you do down into a small, binary SWF file. This has some obvious advantages, mainly that it allows the Flash player to be simpler and not have a full interpreter in it (for example, ActionScript doesn't support eval because there's no way to dynamically execute script at runtime). Back when bandwidth was more constrained it also had the advantage of smaller file sizes and less latency when fetching multiple files.
These were good reasons for their time. However, things have changed. We now have much higher broadband penetration, and the Flash player doesn't have as strong size constraints (though I do agree you want to make sure the size stays small in general -- I've always liked the size constraint Adobe has around their player versus Sun with the Java VM).
At this point, Flash should start working like the web itself: Flex should be pushed right down to the browser and rendered there, with the ActionScript fetched just like SCRIPT tags. In addition, View Source should be on automatically and hooked into the browser's View Source. If I browse to an MXML page and do View Source, I'll see the MXML Flex markup for it. I could also then see the mx:Script tags and view their source as well.
Why this is good:
Flash should implement the HTML 5 History interface and should deeply integrate with the browser's bookmarking and history. I know there were some earlier efforts to have Flash have bookmarking machinery, but its buggy, no one uses it, and it doesn't work very well.
Don't Be Afraid of the Browser
AIR is really cool when you want to build desktop applications using web technologies. However, the browser doesn't need to be routed around as if it were a source of damage, which is what AIR essentially does. Personally I'd rather see Flash deeply embrace the browser itself and expand what can be done there, similar to Gears -- I want the web to grow into the desktop, not have the desktop grow into the web. Flash developers generally see the strengths of the browser as weaknesses, when they shouldn't:
Hyperlinks Are Your Friend
Hyperlinks are essential to the web, navigation, and searching -- it's the Hypertext in HyperText Markup Language (HTML) after all. Flash should embrace linking into the resources that are internally present (such as targeting particular parts of an MXML document). I'm not saying XLink is the way to do this, but perhaps one could mix in an attribute onto an MXML element (or the equivalent of a div and span in some inline text in an MXML element) that makes the element a targetable anchor. Or even better, just automatically make everything targetable:
http://example.com/my_flex_app.mxml#find(Some Text)
The line above would simply find the first occurrence of 'Some Text'. If there are multiple occurrences you can simply choose which one, starting at 1 rather than 0; for example, to target the second occurrence of 'Some Text', you would do the following:
http://example.com/my_flex_app.mxml#find(Some Text)[2]
This is good for search engines, for SEO, and for users. Again, this is just like View Source -- make things linkable by default.
Embrace REST and Readable Remoting Protocols
The Flash remoting protocols are interesting and a nifty piece of engineering. You've got AMF which is essentially a binary RPC protocol, and then you have things like RTMP which lie above this and which can efficiently intermix multiple streams of multimedia to ensure that no channel get's 'starved' if you are doing multiple collaboration or mixing streams together -- nice work. Again, however, this is a case where local efficiency is the enemy of broad adoption. Binary protocols make sense in some cases, but its much better to sacrifice the efficiency of binary protocols for the integration possibilities of textual protocols.
Flash should embrace REST (and if it must have RPC, just do XML-RPC) and layer higher-level protocols above these as HTTP-based protocols. Yes, you're going to sacrifice some efficiency, but it's just much easier for someone to throw up a PHP or Rails based backend that can setup things through REST, spit out some XML-RPC, or do multimedia through something like Jabber.
Embrace SVG
Yes, I know you are creating your own vector-graphics markup language, and I know you just published a long editorial on why SVG wasn't perfect for your needs. I hear what you're saying, but reading through the list it seems like minor errata rather than really good reasons. It seems more like the developer really wanted to make their own thing -- I understand that, it's always more fun to roll your own thing.
SVG's not perfect -- standards never are (and neither was TCP/IP or SMTP versus the competition, BTW). But SVG is actually pretty damn good, and the baseline of support has gotten strong the last year across Firefox, Safari, Chrome and Opera. In the next two years I think we'll start to see SVG emerge as a real tool in most web developers toolkits -- Flash should embrace this. Go ahead and add what you need to it (innovation is okay), but support the core standard itself. It's going to be a little different than the other MXML it's mixed in with, one of the issues you raise, but global systems like the web tend to sacrifice some internal consistency in support of evolvability.
Bonus point: Support the Canvas tag as well, including Web fonts (TrueType, not EOT).
Integrate with HTML and CSS
Yes, HTML has been sitting on its butt for awhile, but things like HTML 5 are starting to make things exciting again, and the work Safari and Firefox have been doing around CSS Effects are really powerful (and really easy for developers to use).
This can be a two-way integration. MXML has some cool ideas around layout, for example, that would be nice to push into HTML, while it would be pretty nifty to start being able to mix HTML and MXML together in some way and styling MXML using CSS. This might also include having one of the open source browsers integrate MXML and aspects of Flash into the layout engine itself. More thought needs to happen around the best way for these particular technologies to integrate.
Make Friends with HTML 5 Video
It would be pretty cool to simply open source and patent-unencumber the FLV format into HTML 5 as the default codec for the HTML 5 Video tag. I might be dreaming (and a bit off about FLV -- I don't know it's technical details deeply), but it never hurts to dream...
Support Both Documents and Applications
The web is good at documents (and with the addition of Ajax relatively okay at applications), while Flash is okay with applications, and not good at documents. The interesting thing about the web is it's actually a spectrum:
Documents <------- Hybrids -------> Applications
What we really need is a technology that can easily adapt along this continuum, creating documents, hybrids like Facebook and MySpace, all the web to full-blown appliations like Gmail and Buzzword, perhaps merging the best ideas of Flash and the HTML web stack. Mark this one as a research area.
Start Working with the W3C and IETF (and/or the Open Web Foundation)
Yeah, I know, working with standards bodies can be a pain. However, it would be pretty cool to have alot of the work happening in Flash flowing into the W3C and IETF (which I know has been happening around Adobe's ActionScript work, but not other aspects). If you want a lighter weight process, you should check out the Open Web Foundation's way of working, which is based on things like OpenID, OAuth, etc. which are a bit more pragmatic than the standards bodies we have today.
Conclusion
At the end of the day Adobe is a tools company, a really damn good tools company actually. Doing the above should allow Adobe to continue creating powerful tools that help authors and content creators while expanding the size of the market they can target.
The above list was just a suggestion to kick things off. The real focus is on having Flash integrate into the web stack better itself (and evolving both Flash and the web stack themselves into the future).
How do you see this happening?
Dion just put up a great post on how Adobe can join the Open Web by open sourcing Flash. I agree with him, and just wanted to add to the conversation a bit.
I've actually been turning this idea around in my head as well. It might surprise you since I'm an Open Web Advocate, but I like Flash. I've always tried to be non-ideological in my work. Flash has done good things and created a great deal of innovation. Adobe (and Macromedia before it) has always been good about evolving Flash forward, including making ActionScript more like JavaScript, embracing markup language development, open sourcing Flex, and more. I'd like to see Flash continue to evolve into being a core part of the Open Web. This would be good for Flash and good for the Open Web.
As Dion points out open sourcing Flash is one big part of making this happen, but another huge aspect would be to have Flash and Flex integrate better into the web stack and be less of a 'black box' on the screen.
Here are some suggested ways to make Flash & Flex more a part of the Open Web -- these are just suggestions. The important point is to integrate Flash and Flex more deeply into how the Open Web works:
- Cross-Platform Standards
- No Vendor Lock-in
- Anyone Can Innovate
- Powerful, Universal Clients
- Open Source Implementations
- Mashable, Searchable, and Integrated
Directly push Flex and ActionScript to the browser and Embrace View Source
Right now Flex and Flash work by compiling everything you do down into a small, binary SWF file. This has some obvious advantages, mainly that it allows the Flash player to be simpler and not have a full interpreter in it (for example, ActionScript doesn't support eval because there's no way to dynamically execute script at runtime). Back when bandwidth was more constrained it also had the advantage of smaller file sizes and less latency when fetching multiple files.
These were good reasons for their time. However, things have changed. We now have much higher broadband penetration, and the Flash player doesn't have as strong size constraints (though I do agree you want to make sure the size stays small in general -- I've always liked the size constraint Adobe has around their player versus Sun with the Java VM).
At this point, Flash should start working like the web itself: Flex should be pushed right down to the browser and rendered there, with the ActionScript fetched just like SCRIPT tags. In addition, View Source should be on automatically and hooked into the browser's View Source. If I browse to an MXML page and do View Source, I'll see the MXML Flex markup for it. I could also then see the mx:Script tags and view their source as well.
Why this is good:
- View Source is a good thing. It's helped to propel the growth of the web itself (and the Ajax community which has benefited hugely from it's existence). It's similar to how YouTube and Flickr made the default option for sharing be public and experienced massive growth -- this made things grow faster versus Snapfish, for example, which made everything private by default. If someone wants to keep their source private they can obfuscate their source just like we do today with JavaScript. View Source should always be on (you can't turn it off) -- just obfuscate your source if you don't want it.
- No compile phase -- the dev experience would become similar to working with HTML and JavaScript today.
- Over time, human readable textual formats have won -- SMTP, HTML, etc. Binary formats are better on paper (and are better in practice many times), but the simplicity of working with textual formats when creating software is just so much easier and is generally worth the efficiency tradeoff. Imagine simple PHP scripts that can just generate MXML, for example -- much easier than trying to emit a binary SWF file from PHP.
Flash should implement the HTML 5 History interface and should deeply integrate with the browser's bookmarking and history. I know there were some earlier efforts to have Flash have bookmarking machinery, but its buggy, no one uses it, and it doesn't work very well.
Don't Be Afraid of the Browser
AIR is really cool when you want to build desktop applications using web technologies. However, the browser doesn't need to be routed around as if it were a source of damage, which is what AIR essentially does. Personally I'd rather see Flash deeply embrace the browser itself and expand what can be done there, similar to Gears -- I want the web to grow into the desktop, not have the desktop grow into the web. Flash developers generally see the strengths of the browser as weaknesses, when they shouldn't:
- The browsers chrome is your friend -- I know you want to get rid of the URL bar and the back and forward buttons for your application, but users depend on this consistent UI. Users spend far more time navigating across many sites than your particular application -- UI consistency in the browser is a good thing. AIR jettisons the browser and loses this -- Flash should expand what web applications can do within the browser itself instead.
- Sandboxing is good - the fact that web applications have limited trust is a feature, not a bug. AIR throws away the sandbox, making it hard for users to effortlessly experiment and try new web sites. Instead, Flash should adopt what Gears and HTML 5 are trying to do, which is to expand the sandbox in a safe and consistent way.
- Users don't want to download applications, they just want to visit URLs - In AIR I have to download an application. Instead, users would rather visit web sites (though having a nice icon on your desktop is a good thing, similar to the Gears Desktop Shortcuts). I'd love if Flash allowed me to drop shortcuts on my desktop to web apps that live at URLs (and which might have cached code locally for performance like the Gears LocalServer, though this would be transparent to the user). However, again, the growth of the web has shown that the ease of simply navigating to URLs (and the safety because of the sandbox) drives huge growth.
Hyperlinks Are Your Friend
Hyperlinks are essential to the web, navigation, and searching -- it's the Hypertext in HyperText Markup Language (HTML) after all. Flash should embrace linking into the resources that are internally present (such as targeting particular parts of an MXML document). I'm not saying XLink is the way to do this, but perhaps one could mix in an attribute onto an MXML element (or the equivalent of a div and span in some inline text in an MXML element) that makes the element a targetable anchor. Or even better, just automatically make everything targetable:
http://example.com/my_flex_app.mxml#find(Some Text)
The line above would simply find the first occurrence of 'Some Text'. If there are multiple occurrences you can simply choose which one, starting at 1 rather than 0; for example, to target the second occurrence of 'Some Text', you would do the following:
http://example.com/my_flex_app.mxml#find(Some Text)[2]
This is good for search engines, for SEO, and for users. Again, this is just like View Source -- make things linkable by default.
Embrace REST and Readable Remoting Protocols
The Flash remoting protocols are interesting and a nifty piece of engineering. You've got AMF which is essentially a binary RPC protocol, and then you have things like RTMP which lie above this and which can efficiently intermix multiple streams of multimedia to ensure that no channel get's 'starved' if you are doing multiple collaboration or mixing streams together -- nice work. Again, however, this is a case where local efficiency is the enemy of broad adoption. Binary protocols make sense in some cases, but its much better to sacrifice the efficiency of binary protocols for the integration possibilities of textual protocols.
Flash should embrace REST (and if it must have RPC, just do XML-RPC) and layer higher-level protocols above these as HTTP-based protocols. Yes, you're going to sacrifice some efficiency, but it's just much easier for someone to throw up a PHP or Rails based backend that can setup things through REST, spit out some XML-RPC, or do multimedia through something like Jabber.
Embrace SVG
Yes, I know you are creating your own vector-graphics markup language, and I know you just published a long editorial on why SVG wasn't perfect for your needs. I hear what you're saying, but reading through the list it seems like minor errata rather than really good reasons. It seems more like the developer really wanted to make their own thing -- I understand that, it's always more fun to roll your own thing.
SVG's not perfect -- standards never are (and neither was TCP/IP or SMTP versus the competition, BTW). But SVG is actually pretty damn good, and the baseline of support has gotten strong the last year across Firefox, Safari, Chrome and Opera. In the next two years I think we'll start to see SVG emerge as a real tool in most web developers toolkits -- Flash should embrace this. Go ahead and add what you need to it (innovation is okay), but support the core standard itself. It's going to be a little different than the other MXML it's mixed in with, one of the issues you raise, but global systems like the web tend to sacrifice some internal consistency in support of evolvability.
Bonus point: Support the Canvas tag as well, including Web fonts (TrueType, not EOT).
Integrate with HTML and CSS
Yes, HTML has been sitting on its butt for awhile, but things like HTML 5 are starting to make things exciting again, and the work Safari and Firefox have been doing around CSS Effects are really powerful (and really easy for developers to use).
This can be a two-way integration. MXML has some cool ideas around layout, for example, that would be nice to push into HTML, while it would be pretty nifty to start being able to mix HTML and MXML together in some way and styling MXML using CSS. This might also include having one of the open source browsers integrate MXML and aspects of Flash into the layout engine itself. More thought needs to happen around the best way for these particular technologies to integrate.
Make Friends with HTML 5 Video
It would be pretty cool to simply open source and patent-unencumber the FLV format into HTML 5 as the default codec for the HTML 5 Video tag. I might be dreaming (and a bit off about FLV -- I don't know it's technical details deeply), but it never hurts to dream...
Support Both Documents and Applications
The web is good at documents (and with the addition of Ajax relatively okay at applications), while Flash is okay with applications, and not good at documents. The interesting thing about the web is it's actually a spectrum:
Documents <------- Hybrids -------> Applications
What we really need is a technology that can easily adapt along this continuum, creating documents, hybrids like Facebook and MySpace, all the web to full-blown appliations like Gmail and Buzzword, perhaps merging the best ideas of Flash and the HTML web stack. Mark this one as a research area.
Start Working with the W3C and IETF (and/or the Open Web Foundation)
Yeah, I know, working with standards bodies can be a pain. However, it would be pretty cool to have alot of the work happening in Flash flowing into the W3C and IETF (which I know has been happening around Adobe's ActionScript work, but not other aspects). If you want a lighter weight process, you should check out the Open Web Foundation's way of working, which is based on things like OpenID, OAuth, etc. which are a bit more pragmatic than the standards bodies we have today.
Conclusion
At the end of the day Adobe is a tools company, a really damn good tools company actually. Doing the above should allow Adobe to continue creating powerful tools that help authors and content creators while expanding the size of the market they can target.
The above list was just a suggestion to kick things off. The real focus is on having Flash integrate into the web stack better itself (and evolving both Flash and the web stack themselves into the future).
How do you see this happening?
Labels: flash, html5, open web
Thursday, March 13, 2008
Easy Download of Dojo Storage for Developers
I've put up a simple ZIP file that has just Dojo Storage. This is an optimized build of Dojo with just the small files necessary to use Dojo Storage. I've also created a simple Hello World example that folks can use to get started with Dojo Storage quickly. Note that this is a pre-release version of Dojo 1.1 which is coming out soon but has not been wrapped up yet. This version has a fully functioning Flash Storage Provider, HTML 5 storage, and Google Gears storage.
Labels: dojo, dojo storage, flash, flash storage provider, gears
Saturday, June 16, 2007
Cool Demo Using Dojo Storage
Lucas Birdeau, one of the TIBCO GI folks, pointed me to this awesome Ajax web site he created with Dojo Storage and the Flash storage provider. He emailed me recently:
I just wanted to let you know that I had been using dojo storage on several GI applications and have had a really good experience. With all of the marketing behind the new entrants to this space, I think I've got a pretty robust implementation of dojo storage that really showcases how mature your technology is. Feel free to check it out. It's just a personal page that I put together on the side. It's a reorganization of craigslist that uses dojo storage to save and annotate posts.
http://remixedby.us/
I just wanted to let you know that I had been using dojo storage on several GI applications and have had a really good experience. With all of the marketing behind the new entrants to this space, I think I've got a pretty robust implementation of dojo storage that really showcases how mature your technology is. Feel free to check it out. It's just a personal page that I put together on the side. It's a reorganization of craigslist that uses dojo storage to save and annotate posts.
http://remixedby.us/
Labels: dojo, dojo storage, flash
Thursday, June 07, 2007
Moving On: Coworking, Really Simple History, and Flash Storage
Every so often I look back over the projects I'm doing and take stock. I have a little inner thermometer that I check in on from time to time, and if I'm feeling stressed out and not having fun anymore it gives me information and a clue that I need to revisit what I've been doing. When I feel this, I create a Not Do Do List and figure out stuff that I need to let go of. Lately, I've been feeling stressed out and not having as much fun, feeling like there is a monkey on my back, so I've been doing things like morning pages, meditation, visual journaling, and other stuff to see what I need to change.
On a deeper level, I've been looking over what I'm good at and what I'm not good at. It seems my natural role is as an inventor pragmatist. I initially create an idea that is different than what is out there, envisioning something wierd and different, then do the hard work of making it initially pragmatic and real to prove to the world that it should be taken seriously whereas before it was ignored. Then, about a year or two down the line, others show up who have other skills that I am not as good at but are very important at this stage, such as community building, event planning, and more. I'm really good at brainstorming an idea, prototyping it, and then taking it into the initial reality stage with working code that can be used in the real world, in real software. I'm good at release 1 and 1.5, but not as good at release 2 and release 3. I'm not good at organizing groups of people, creating events, or cranking on the same code base once the initial idea and implementation has been proven to the community. I used to beat myself up about this, but I've realized that I just have to focus on what I'm good at and create situations where others can help me at the things I'm not as good at.
I've realized there are a number of projects that I created that have moved beyond this initial phase and are now successful and standing on their own legs, and it's time for me to find new maintainers for them and let them go, put them on my personal Not To Do List so to speak. These are coworking, the Really Simple History library, and Flash-based client-side storage. I need to find new maintainers for some of these projects so I can focus more time and attention on Dojo Offline. Also remember that almost all of the time I spend on these projects is free-time that I don't get paid for, and I only have so many hours in the day to hack on cool new stuff.
Coworking
I created coworking about 2 years ago. I had been working for a startup, Rojo, and wanted to go into business for myself as a consultant. However, I somehow wanted the community and structure of a workplace with the independence and freedom of working for myself, so I created coworking. Coworking was a way for independent contractors and workers to have a common space to work from, rather than hacking from home, with a more community minded focus. I rented some funky space from a small non-profit called Spiral Muse and ran it for about 8 months. Through a nice coincidence the Spiral Muse space was where I met my sweetheart, Bekka Fink, at a party months before. We couldn't store permanent stuff at the space, so I had to setup folding card tables every morning when I got there then break them down at the end of the day. For the first month I had no one, and just went to the space and worked there by myself, going through the action of setting up the folding card tables and wondering if anyone would ever show up. Eventually I had a full house, with an eclectic group of folks: a screenplay writer, a computer researcher, an open source hacker rolling his own computer language, and others.
From time to time people would drop by who were interested in the idea of coworking but weren't able to join the Spiral Muse space. I would tell them "if you were to steal this idea and make it your own, what would you do?" They would then wander off, a seed planted.
I had to close the Spiral Muse space after about 8 months since it was hard to grow within it's small size and it was getting hard to staff it; during that time those folks who had dropped by to check out the space started banding together to create an even better space, one that was larger and open more days of the week. This was the Hat Factory space, in San Francisco.
Since then coworking has spread around the world, with spaces already in or forming in New York, Paris, and more. There is an active Google Group with hundreds of members and a very active wiki. Coworking has been covered by Business Week, the New York Post, and more. Chris Messina and Tara Hunt are now the most active leaders of the coworking movement and are instrumental in moving it forward, creating events, organizing, and more. I've stepped out of an organizing role in the coworking movement to focus on other projects and am no longer a member of a space.
Really Simple History
I created the Really Simple History (RSH) library about two years ago. It was one of the first libraries to effectively solve the history and bookmarking issues inherent with Ajax applications. I had two goals with RSH: one, to show that history and bookmarking were important in Ajax applications (most developers at the time thought you could just throw this feature out and ignore that you were working in a browser); and two, that you could achieve this in contemporary web browsers using various browser tricks.
Today, RSH is used by a huge number of websites to solve Ajax bookmarking and history issues; it is also integrated into alot of other open source projects. Members from the Yahoo YUI team and the Google GWT team have told me that the BSD-licensed Really Simple History code base and techniques were instrumental in their own history libraries. RSH has been written up in online articles and books, and is now used by developers in their daily practice. Respecting the back button and creating a bookmark mechanism are now accepted practices in the Ajax industry, so I don't need to beat that drum anymore.
Unfortunately, I have not been able to do any real work on RSH for about 1 1/2 years. Important work remains: doing better QA on Internet Explorer 7, using one of the various Safari history/bookmarking techniques that have been discovered, fixing some bugs that can occur in various edge cases, and more. My focus on Dojo Storage and Dojo Offline have not allowed me to do work on this library; I am constantly getting emails with bug fixes and inquiries, and I feel terrible that I haven't gotten a new release out the door for awhile.
I am looking for a new maintainer for the RSH library. I want to make sure I find someone who will treat it well because alot of folks depend on it, so if you are interested please email me (bkn3 AT AT columbia.edu) and give me your qualifications, open source experience, and where you plan on taking the library.
Flash-Based Client-Side Storage
I've been hacking on the offline web problem for a few years. I knew before I could work on offline access to an application's user-interface, though, I had to figure out how to store data permanently on the client-side, beyond the 4K cookie limit. About 2 1/2 years ago I started searching around for a way to do this, experimenting with giant bookmarklets and other wierd stuff to see if I could find a clever back door. I then realized I could use a hidden Flash applet to store megabytes of info.
I rolled a prototype of this Flash based storage called AMASS (Ajax Massive Storage System) to see if the idea was tenable, and it turned out to work well. I then rolled another version of it and refactored it into Dojo, and got it to work in Safari as well; I also did a bunch of (grotty/interesting) hacks to get it super-fast for storing large datasets.
Once Flash-based storage stabilized, I moved on to the other part of the offline problem, which is finding your user-interface when you are away from the network, and rolled Dojo Offline in partnership with SitePen. Of course, one month after we released Google released Google Gears, a similar offline solution, so we created a partnership with them to port the Dojo Offline APIs on top of Gears. I'm in the middle of coding that port now. The next release of Dojo Offline will include a Dojo SQL module to use SQL-based storage, and a new Dojo Storage provider that uses Gears to store its data. Dojo Offline will no longer be dependent on the Flash Dojo Storage provider or the Firefox 2 Dojo Storage provider, and I would like to find a new maintainer for those. My preference for client-side storage is now to use Dojo Storage in conjunction with Google Gears. There are a number of startup companies that are using the Flash storage provider, however, and many users have told me they want to keep it; there are a number of enterprises that are also using it. I will port the Flash Storage Provider to the new Dojo 0.9 release that is coming out soon, but moving forward I would only like to personally maintain the GearsStorageProvider and the public Dojo Storage API. There are a number of cool performance and bug fixes that folks would like to get into the Flash Storage Provider, and this would be a great way to get your feet wet with the Dojo project. Please email me (bkn3 AT AT columbia.edu) your qualifications, open source experience, and future plans for the Flash Storage Provider if you would like to take this on.
On a deeper level, I've been looking over what I'm good at and what I'm not good at. It seems my natural role is as an inventor pragmatist. I initially create an idea that is different than what is out there, envisioning something wierd and different, then do the hard work of making it initially pragmatic and real to prove to the world that it should be taken seriously whereas before it was ignored. Then, about a year or two down the line, others show up who have other skills that I am not as good at but are very important at this stage, such as community building, event planning, and more. I'm really good at brainstorming an idea, prototyping it, and then taking it into the initial reality stage with working code that can be used in the real world, in real software. I'm good at release 1 and 1.5, but not as good at release 2 and release 3. I'm not good at organizing groups of people, creating events, or cranking on the same code base once the initial idea and implementation has been proven to the community. I used to beat myself up about this, but I've realized that I just have to focus on what I'm good at and create situations where others can help me at the things I'm not as good at.
I've realized there are a number of projects that I created that have moved beyond this initial phase and are now successful and standing on their own legs, and it's time for me to find new maintainers for them and let them go, put them on my personal Not To Do List so to speak. These are coworking, the Really Simple History library, and Flash-based client-side storage. I need to find new maintainers for some of these projects so I can focus more time and attention on Dojo Offline. Also remember that almost all of the time I spend on these projects is free-time that I don't get paid for, and I only have so many hours in the day to hack on cool new stuff.
Coworking
I created coworking about 2 years ago. I had been working for a startup, Rojo, and wanted to go into business for myself as a consultant. However, I somehow wanted the community and structure of a workplace with the independence and freedom of working for myself, so I created coworking. Coworking was a way for independent contractors and workers to have a common space to work from, rather than hacking from home, with a more community minded focus. I rented some funky space from a small non-profit called Spiral Muse and ran it for about 8 months. Through a nice coincidence the Spiral Muse space was where I met my sweetheart, Bekka Fink, at a party months before. We couldn't store permanent stuff at the space, so I had to setup folding card tables every morning when I got there then break them down at the end of the day. For the first month I had no one, and just went to the space and worked there by myself, going through the action of setting up the folding card tables and wondering if anyone would ever show up. Eventually I had a full house, with an eclectic group of folks: a screenplay writer, a computer researcher, an open source hacker rolling his own computer language, and others.
From time to time people would drop by who were interested in the idea of coworking but weren't able to join the Spiral Muse space. I would tell them "if you were to steal this idea and make it your own, what would you do?" They would then wander off, a seed planted.
I had to close the Spiral Muse space after about 8 months since it was hard to grow within it's small size and it was getting hard to staff it; during that time those folks who had dropped by to check out the space started banding together to create an even better space, one that was larger and open more days of the week. This was the Hat Factory space, in San Francisco.
Since then coworking has spread around the world, with spaces already in or forming in New York, Paris, and more. There is an active Google Group with hundreds of members and a very active wiki. Coworking has been covered by Business Week, the New York Post, and more. Chris Messina and Tara Hunt are now the most active leaders of the coworking movement and are instrumental in moving it forward, creating events, organizing, and more. I've stepped out of an organizing role in the coworking movement to focus on other projects and am no longer a member of a space.
Really Simple History
I created the Really Simple History (RSH) library about two years ago. It was one of the first libraries to effectively solve the history and bookmarking issues inherent with Ajax applications. I had two goals with RSH: one, to show that history and bookmarking were important in Ajax applications (most developers at the time thought you could just throw this feature out and ignore that you were working in a browser); and two, that you could achieve this in contemporary web browsers using various browser tricks.
Today, RSH is used by a huge number of websites to solve Ajax bookmarking and history issues; it is also integrated into alot of other open source projects. Members from the Yahoo YUI team and the Google GWT team have told me that the BSD-licensed Really Simple History code base and techniques were instrumental in their own history libraries. RSH has been written up in online articles and books, and is now used by developers in their daily practice. Respecting the back button and creating a bookmark mechanism are now accepted practices in the Ajax industry, so I don't need to beat that drum anymore.
Unfortunately, I have not been able to do any real work on RSH for about 1 1/2 years. Important work remains: doing better QA on Internet Explorer 7, using one of the various Safari history/bookmarking techniques that have been discovered, fixing some bugs that can occur in various edge cases, and more. My focus on Dojo Storage and Dojo Offline have not allowed me to do work on this library; I am constantly getting emails with bug fixes and inquiries, and I feel terrible that I haven't gotten a new release out the door for awhile.
I am looking for a new maintainer for the RSH library. I want to make sure I find someone who will treat it well because alot of folks depend on it, so if you are interested please email me (bkn3 AT AT columbia.edu) and give me your qualifications, open source experience, and where you plan on taking the library.
Flash-Based Client-Side Storage
I've been hacking on the offline web problem for a few years. I knew before I could work on offline access to an application's user-interface, though, I had to figure out how to store data permanently on the client-side, beyond the 4K cookie limit. About 2 1/2 years ago I started searching around for a way to do this, experimenting with giant bookmarklets and other wierd stuff to see if I could find a clever back door. I then realized I could use a hidden Flash applet to store megabytes of info.
I rolled a prototype of this Flash based storage called AMASS (Ajax Massive Storage System) to see if the idea was tenable, and it turned out to work well. I then rolled another version of it and refactored it into Dojo, and got it to work in Safari as well; I also did a bunch of (grotty/interesting) hacks to get it super-fast for storing large datasets.
Once Flash-based storage stabilized, I moved on to the other part of the offline problem, which is finding your user-interface when you are away from the network, and rolled Dojo Offline in partnership with SitePen. Of course, one month after we released Google released Google Gears, a similar offline solution, so we created a partnership with them to port the Dojo Offline APIs on top of Gears. I'm in the middle of coding that port now. The next release of Dojo Offline will include a Dojo SQL module to use SQL-based storage, and a new Dojo Storage provider that uses Gears to store its data. Dojo Offline will no longer be dependent on the Flash Dojo Storage provider or the Firefox 2 Dojo Storage provider, and I would like to find a new maintainer for those. My preference for client-side storage is now to use Dojo Storage in conjunction with Google Gears. There are a number of startup companies that are using the Flash storage provider, however, and many users have told me they want to keep it; there are a number of enterprises that are also using it. I will port the Flash Storage Provider to the new Dojo 0.9 release that is coming out soon, but moving forward I would only like to personally maintain the GearsStorageProvider and the public Dojo Storage API. There are a number of cool performance and bug fixes that folks would like to get into the Flash Storage Provider, and this would be a great way to get your feet wet with the Dojo project. Please email me (bkn3 AT AT columbia.edu) your qualifications, open source experience, and future plans for the Flash Storage Provider if you would like to take this on.
Labels: ajax, coworking, dojo offline toolkit, dojo storage, flash, flash storage provider, personal, projects, rsh, storage
Subscribe to Posts [Atom]
