incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Meadors <larry.mead...@gmail.com>
Subject Re: Project Proposal: Subvertive
Date Fri, 22 Jul 2005 16:50:29 GMT
Uhm, +1?

;-)

Larry


On 7/22/05, Davanum Srinivas <davanum@gmail.com> wrote:
> 
> ROTFL :) :) :) For a second i was trying to figure out if i overslept
> and today is April 1st :)
> 
> -- dims
> 
> On 7/22/05, Upayavira <uv@odoko.co.uk> 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 <http://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:
> >
> > subvertive-users@incubator.apache.org
> >
> > subvertive-discuss@incubator.apache.org
> >
> > subvertive-reorg@incubator.apache.org
> >
> > subvertive-ppmc@incubator.apache.org
> >
> > 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 general@incubator, so as not to polute the real discussions going on
> > here :-)
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
> 
> 
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message