incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: Project Proposal: Subvertive
Date Thu, 28 Jul 2005 21:51:00 GMT
Reading over it, I think it actually says that.

I can attest to the fact that beer was involved in the initial design  
process of this thing...


On Jul 28, 2005, at 5:45 PM, Larry Meadors wrote:

> I think that was to be a part of the 1.1 release?
>
> Larry
>
>
> On 7/28/05, Geir Magnusson Jr. <geirm@apache.org> wrote:
>
>>
>> You forgot to mention the part where it will byte-weave the compiled
>> diff into the classfile...
>>
>> geir
>>
>> On Jul 22, 2005, at 12:22 PM, Upayavira 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
>>>
>>>
>>>
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message