incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: Project Proposal: Subvertive
Date Fri, 22 Jul 2005 16:46:14 GMT
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
> 
> 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
View raw message