ROTFL :) :) :) For a second i was trying to figure out if i overslept and today is April 1st :)
-- dims On 7/22/05, Upayavira <[EMAIL PROTECTED]> wrote: > Subvertive Incubator Proposal > -------------------------- > Here is a proposal for an incubator project that originally arose over > beers at ApacheCon EU 2005, and was received with thunderous applause > during the lightning talks at that same ApacheCon. > > Introduction > ------------ > Java, when first introduced, proposed mobile code. This proposal offers > an extension to the definition of mobile code, allowing code to transfer > between developer and application, server and client, dynamically, at > runtime. > > It proposes a classloader that, whenever a class is loaded, checks with > a subversion repository for changes to the class, downloads diffs and > compiles the class before executing it. > > Sponsoring Members > ------------------ > Below are the Apache members who put their names behind this > proposal: > > Erik Abele > Danny Angus > Noel Bergman > Stefan Bodewig > Ken Coar > David Crossley > Torsten Curdt > Bertrand Delacretaz > Lars Eilebrecht > Justin Erenkrantz > Brian Fitzpatrick > Santiago Gala > Martin Kraemer > Raphael Luta > Geir Magnusson Jr > Jeremias Maerki > Giacomo Pati > Gianugo Rabellino > Cliff Schmidt > Henning Schmiedehausen > Leo Simons > Sander Striker > Upayavira > Sylvain Wallez > Dirk Willem Van Gulik > Carsten Ziegeler > > Below are the apache committers and other respected community members > who wish to show their support for this project: > > Ugo Cei > Marcus Crafter > Daniel Fangerstrom > Brian McCallister > Alfred Nathaniel > Ruediger Pluem > Dalibor Topic > Mladen Turk > > This proposal would like to offer this as the default classloader for > the Harmony project. An official statement from Harmony was made about > this project: > > "Harmony is interested in how this might develop" > > Use Case > -------- > Imagine a scenario. You have been called by a user who is using your > software. They tell you that a popup has appeared saying "Null Pointer > Exception" with a "mail it" button. You ask them to click on that > button, and it mails you a stack trace. You can see a straightforward > fix, which you commit to Subversion, and tell them to try it again. > Their classloader checks Subversion, finds a change, downloads a diff, > compiles, reloads the class and this time the user's application runs > without flaw. > > Note, this dynamic would work via mailing lists too - imagine mailing a > mailing list and hearing soon that a commit has been done to fix it, and > your web server just starts working again. > > Subversion > ---------- > As Java can easily support HTTP requests, and there is already a JCI > project within Jakarta (the Compiling Class Loader). Thus, in > combination, the basic idea underlying this proposal would be very easy > to implement with existing components. > > CVS > --- > However, not all projects use Subversion (SVN). Therefore, support for > CVS will be required. An extension will be added that allows the > classloader to talk the CVS pserver protocol. > > Some firewalls block pserver. Therefore, we will also allow the > classloader to download the class changes via a viewcvs installation. > And so that the maintainers of the viewcvs installation don't need to > worry unnecessarily, we will set the user agent string used to that of > Internet Explorer, so that it is not possible to identify requests from > this classloader. > > Google > ------ > Imagine the scenario whereby a classloader is asked for a class that it > doesn't know about. It does not exist in any of the SVN or CVS > repositories known by the classloader. Therefore, the classloader will > be extended to do a search for the class on Google, It will locate the > classes original SVN or CVS server, download the class from that server, > compile, and your application will just work with the class that > couldn't be found. > > An insider from Google said about this proposal: "We can support the > load [caused by this classloader]". > > This almost entirely kills the need for complex classpaths. Doesn't Java > get so much easier? > > Mailing List Archives > --------------------- > Imagine an unlikely scenario where a Subversion server is not available, > down for maintenance or such. This can be handled by, again with Google, > searching mailing list archives for commit mails, and rebuilding the > class from these diffs. > > Developer Support > ----------------- > The classloader will have additional support specifically for developers. > > Firstly, it can be configured to use a Swing client, which, when a class > compilation fails, will pop up a Swing window, which allows the > developer to fix the problem. Clicking submit will cause the classloader > to recompile the new class. If it correctly compiles, it will also, > optionally, commit the change back to the SVN repository. > > Where the application is running remotely, it will be possible for the > classloader to send an IM or IRC message to the developer (based upon > the Javadoc author tag) with the stacktrace. By reply, the author can > provide a diff that will be used by the classloader when reloading the > class. Again, the classloader can be used to recommit the change back to > the repository. > > Where IM is not practicable, the stacktrace will be mailed to the > project's mailing list, such that a fix can be arrived at promptly. > > Finally, an extension to the classloader will allow it to run Junit > tests against the class before loading it. The above methods will be > used to gain a correction if the tests fail. > > Extensions > ---------- > The classloader could be optimised to use bytecode manipulation when a > diff is downloaded. Thus, only the diff needs to be recompiled, speeding > the reloading of the class. > > Given the number of features described above, modularity is going to be > important. Therefore, it is proposed that OSGi be used as an underlying > framework for managing this modularity. > > Conclusion > ---------- > With all of the above functionality, build tools, such as Ant, or Maven, > will no longer be required. Development work becomes so much more > effective, using software becomes more immediate, and we can finally > truly call our software development methodologies 'agile'. > > Required Resources > ------------------ > We are aiming to become a top-level project, > > subvertive.apache.org > > potentially with several subprojects for e.g. integrating with other > version control systems such as Visual SourceSafe and implementations of > this concept in different languages. We plan to target at least the .Net > CLR and the Parrot VM. > > Initial mailing lists: > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > Note we believe that niether a commits mailing list nor a development > mailing list will be necessary as development shall after an initial > bootstrapping period shall be taking place completely through the > Subvertive Swing interface. > > Issue tracking: > > Jira please. > > Source repositories: > > In order to make it more likely that we will provide support early on > for the widest range of SCM systems, we would like to request both CVS > and SVN repositories, both named subvertive. > > IP Issues and Known Patents > --------------------------- > Several of the initial sponsors have informed us that they believe they > may have relevant patents in this field. The CVSGrab developers have > informed us that they have a patent pending regarding the IE browser > emulation. However, all these parties have agreed to provide us with > non-exclusive licenses under the proper RAND terms. > > Dependency on salaried developers > --------------------------------- > Considering the strong support for this project gathered during just 5 > minutes at the ApacheCon conference, we are confident that this will not > be an issue. In fact, several companies have indicated they are > considering firing their developers if they push this forward, so we > should be fine. > > The Future > ---------- > When we have got a prototype working, and a specification written, this > specification will be put to the JCP as a JSR. The target date for doing > this will be the first day of April. > > +1 from us. What do you think? > > - Upayavira and listed supporters, 22 July 2005 > ApacheCon EU 2005 > > P.S. Congratulations if you got this far. In case you haven't worked it > out yet, this is nothing more than a joke. Please carry on all > discussion on this proposal on the community@apache.org list rather than > on [EMAIL PROTECTED], so as not to polute the real discussions going on > here :-) > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas -http://blogs.cocoondev.org/dims/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
