Weekly Edition
Return to the Front pageSponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
|
| |||||||||||
Freeing web services with ForkolatorThe next battle in the war for software and data freedom is likely to be in the online services realm. There are already calls for legislation to govern what Gmail and Facebook can do with your data along with efforts to provide free alternatives to some popular web applications. Coming at the problem from a different direction, the Forkolator project is looking toward a world where free web applications are not only free to change, but those changes are immediately available to use on the same site. Many of the web applications that people use today are not free in any sense other than price. There are also lots of applications that are free software – Wikipedia and Wordpress are often used as examples – but changing the source code for them does little to change the user's experience, because the service controls the software version that they run. This is as it should be, few would argue that Wikipedia should be forced to run some modified version of their code. Vast quantities of collaboratively developed data reside there, however, that any modified version of Wikipedia would want to access. Currently, one could work with the Wikipedia folks to get the change integrated into their codebase and eventually rolled-out for users, or one could fork the project. The Forkolator vision – at this point it is not much more than that – is to provide a third choice. In a mockup of the Wordpress management interface, Forkolator founder Erik Pukinskis added a "fork this page" button. Somewhere down the road, if Wordpress were written to support Forkolator, that button would instantiate a copy of the server code running on the server, with access to all the same data. It would then allow a user to change the underlying code to fix a bug or add a feature, which would then run live in that instance. Users who accessed the weblog or management screen would use the updated code. Obviously, people that are able to host their own Wordpress instances are able to do this already – it is free software after all. What may be missing is the collaborative environment that a blog hosted at wordpress.com provides. Wordpress is free software, but wordpress.com does not provide a free, as in freedom, service. Likewise for Wikipedia, most of the value is in the site itself and the data; even forking it only gives a static version at the point of the fork. The Forkolator concept would provide another level of freedom; one could have their own view of Wikipedia running side-by-side with the standard code, allowing users to decide which they preferred. At the moment, Forkolator is a PHP application that provides a web-based integrated development environment (IDE) that can be forked and modified live. It provides a kind of proof-of-concept; an IDE running in the browser may not provide the ideal development environment. Ruby on Rails already has Heroku, which shares many traits with the Forkolator vision. The focus of Heroku seems to be avoiding the pain of deploying an individual web application rather than Forkolator's explicit push for freedom in the web services arena. The problems inherent in allowing users to modify the function of a server-side application are legion. Forkolator advocate Sandy Armstrong calls the problems "staggering" and they are; providing security, privacy, and stability while still allowing user modification is uncharted territory. Solving those problems in a sensible fashion will make or break the project and it is far from clear that they can be solved. There is talk that some of the problems inherent in the model could be solved in the same way that wiki defacements are handled; by the community. If a rogue user modified the web application to be a spambot, for example, other users could shut down or quarantine the fork. Data access is another area that will need close attention. Obviously the application needs read and write access to the database, but how can you keep rogue applications from trashing the data for everyone else? This goes well beyond defacing individual pages, wholesale removal of all content could be effected by a malicious application. The Forkolator team will need to come up with ways to deal with all of these kinds of problems and more. Forkolator is in its infancy – perhaps gestation is more accurate – with an enormous number of serious technical hurdles to overcome, but it does provide an interesting view of how free web services could work. It is not a model that all web applications will adopt, with good reason, but for sites that are largely collaborative in nature, it could make a great deal of sense. Whether Forkolator, Heroku, or some other framework can actually deliver the vision remains to be seen. We will be watching. (Log in to post comments)
Gestation? Posted Nov 29, 2007 1:28 UTC (Thu) by ncm (subscriber, #165) [Link] Sounds to me like it's still well short of actual conception. I would place it at "fumbling with buttons".
Gestation? Posted Nov 29, 2007 8:29 UTC (Thu) by grouch (subscriber, #27289) [Link]
Absolutely, geekily, recursively hilarious. I am in tears and awe. Thank you.
Gestation? Posted Nov 29, 2007 14:26 UTC (Thu) by nix (subscriber, #2304) [Link] It feels NNTP-like to me. i.e., the right approach to this involves app forks talking via some well-defined protocol to each other, which protocol can exchange the code of the app itself and flood-fill the other data from app to app. Something like NoCeM could then be used to instantiate a web-of-trust atop this layer. (Design? I don't have anything but a `this feels right', not really.)
Gestation? Posted Nov 30, 2007 4:25 UTC (Fri) by njs (subscriber, #40338) [Link] You don't use NNTP, you use the data structures and stateless synchronization protocols invented for modern DVCSes.
Gestation? Posted Nov 30, 2007 8:20 UTC (Fri) by nix (subscriber, #2304) [Link] They'd serve: they do the flood-fill part as well. But what we still need is a web-of-trust, so you can ignore nodes and everything flowing through them if you want to.
I'm trying to see it. Posted Nov 29, 2007 1:52 UTC (Thu) by kbob (subscriber, #1770) [Link] On the face of it, Forkolator sounds like a bad idea. If you want to remap the user experience, you can use a browser-side tool like GreaseMonkey. If the server's owners want to allow new mashup apps, they can provide application-specific web services APIs. I'm not sure how much of a problem Forkolator could solve that those two approaches don't, and it has to solve pretty compelling problems to be worth the effort and security risks. But I'll keep an open mind. I've failed to see the Next Big Thing enough times before...
agreed Posted Nov 29, 2007 14:57 UTC (Thu) by ccyoung (subscriber, #16340) [Link] running wep apps myself, I put detailed (vs global) security issues at the page level. since almost all web sql uses global, not individual logins, due to the cost of session management (or lack of db sophistication), there would need to be an expensive (performance and development) security layer between the page and the data. the base idea is great, but for me greasemonkey is the way my users would need to go. perhaps on the page I could send a lot of data in hidden or display:none block that they could in turn enable / disable / rearrange / whatever. end users (in my case at the company level) customizing their pages is a very exciting idea - well beyond my standard offering of customized menus and css properties.
greasemonkey Posted Nov 30, 2007 9:22 UTC (Fri) by phip (subscriber, #1715) [Link] I have very limited experience with greasemonkey (actually, only the fancyLWNComments script: http://lwn.net/Articles/249618/). The script is awesome, but it is a real pain when reading LWN from multiple computers. It would be really cool if I could store the script and associated state somewhere on an LWN server, so that it is automatically downloaded and executed on my computer whenever I login to LWN. Extra credit if it can be made to work without installing greasemonkey on the computer I'm surfing from. This could give a fairly big chunk of what Forkolator is trying to achieve, without executing user code on the servers.
Freeing web services with Forkolator Posted Nov 29, 2007 2:03 UTC (Thu) by walters (subscriber, #7396) [Link] I put together some thoughts on Forkolator here: http://cgwalters.livejournal.com/11145.html
Freeing web services with Forkolator Posted Nov 29, 2007 9:57 UTC (Thu) by smurf (subscriber, #17840) [Link] Holy flying crapload! If you want to protect data from mass deletion or defacement, you need an architecture which gives you that protection. In other words, some sort of RPC interface (doesn't *have* to be XMLRPC :-) instead of direct SQL access. There's simply no other way to do this safely. And I haven't even started on PHP and its security model, which is woefully inadequate for a task like this, no matter what you do. (So is that of every other common programming language, except possibly Java. Maybe. If you're lucky, disable stuff like introspection, etc. etc.) It should surprise nobody that if you have that, you can just offer (suitably protected) access to *that* to anybody who'd like to run a modified version of your server, instead of letting people run their code on yours (which has its own security problems).
Freeing web services with Forkolator Posted Nov 29, 2007 14:44 UTC (Thu) by sepreece (subscriber, #19270) [Link] Hmm. Maybe you could do a copy-on-write approach to the site's data. When you forked the source, your copy of the source would also get a "virtual fork" of the site's data that would just use the site's original data until you changed something, then the change would stay local to the version that was visible to your fork of the software. I agree with smurf that the idea of letting people fork the software but use it to modify the site's data directly is unmanageably permissive. Linus doesn't let you directly modify his tree...
Freeing web services with Forkolator Posted Nov 29, 2007 19:56 UTC (Thu) by smurf (subscriber, #17840) [Link] Copy-on-write sounds like a good idea, except that (a) you'd need database support for it, (b) you still have the "anybody could read everybody's personal data and crack their passwords" problem.
Freeing web services with Forkolator Posted Nov 30, 2007 1:33 UTC (Fri) by sepreece (subscriber, #19270) [Link] Sure - I was assuming access controls would still be in place for private data and only talking about an approach to allowing software forks to work on communal sites.
Freeing web services with Forkolator Posted Nov 29, 2007 11:04 UTC (Thu) by NAR (subscriber, #1313) [Link] I think that the difference between Forkolator and writing a GreaseMonkey/Userjs script or using an API is that in this case the user does get server resources beyond the data stored on the server. The "you can copy the software freely" works because the actual copying of the software is done at virtually no cost. However, the provided resources are costing someone some non-negligible amount of money. Sourceforge, etc. (they are also providing resources) could sustain itself based on advertisements, donations, etc. but at least the advertisements model doesn't seem to work in this case, it won't generate revenue to pay for the power consumption of the server.
Freeing web services with Forkolator Posted Nov 29, 2007 11:27 UTC (Thu) by copsewood (subscriber, #199) [Link] I agree. I think for this concept to work the party that wants a fork will have to provide the fork within their own domain name identity and at their own server cost. The domain name identity is needed so that better or worse forks can acquire their own reputation independent of the parent node. As far as server cost is concerned, those wanting a fork should either have to put their money where their mouth is or find a sponsor (e.g. on the sourceforge model) willing to host them. I think it somewhat unlikely that a hoster of a useful data collection with a free software license wanting more flexible use of this data would want to write a blank cheque in connection with the cost of supporting community experiments on code functionality. Using virtual machines or alternative hosts, for forks with their own distinctive identity, where there is some accountability for server costs and unacceptable software features is the way to go.
I like the name Heroku! Posted Dec 9, 2007 16:53 UTC (Sun) by moxfyre (subscriber, #13847) [Link] Heroku is a cute name... it's likely just the Japanese pronunciation of the English word "fork." Nearly all Japanese syllables have a consonant-vowel structure, and the [f] sound is an allophone of [h], so "heroku" is the natural Japanese pronunciation of the word! (Likewise, many Japanese companies have names that are pronounced differently in Japan, like Pentax the camera company which is called "Pentakusu.")
Freeing web services with Forkolator Posted Dec 11, 2007 23:25 UTC (Tue) by Baylink (subscriber, #755) [Link] As someone who's spent 25 years designing applications, mostly database backed, my snap reaction to this is "wow, a lot of people are gonna waste a whole lot of time -- theirs and other people's -- before they figure out that there's no practical way to do this." The problem is that applications need, at the very least, to be under one adminstrative span of control, if not the hand of a single architect. We have enough problems with the (theoretically) useful concept of object/module reuse -- have you ever worked with any sufficiently complex application that depends on enough other packages? I have, and let me tell you, dependency hell is *not* enjoyable. I can think of at least a couple projects that deal with the issue by bringing along their own copies of every other package they use, because the cross-dependencies are complex enough to make trying to maintain everything impractical, never mind what happens if your auto-update utility bumps something. And now you want to let $RANDOMs in to write code against your datastore? Hee. This will be fun to watch.
|
|||||||||||