Re: How to package a contribution
Hello all, What about dual-licensed stuff. E.g. I want to contribute some code under ASL and GPL. Is this okay at all? From what I read so far it seemed you allow only ASL-licensed code. Cheers, Michael -- Michael Koch Senior Developer Enough Software Vor dem Steintor 218 28203 Bremen Germany Web: http://www.enough.de Mail: [EMAIL PROTECTED] Tel: +49-(0)421-9889131 Fax: +49-(0)421-9889132
Re: How to package a contribution
On Sep 26, 2005, at 7:52 AM, Michael Koch wrote: Hello all, What about dual-licensed stuff. E.g. I want to contribute some code under ASL and GPL. Is this okay at all? From what I read so far it seemed you allow only ASL-licensed code. We will have AL (Apache License, rather than the old Apache Software License) code here - if you wish to make it available under the GPL also somewhere, you are certainly free to do that, and I personally encourage it to help bring the communities together. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Robert Schröder/PROFI/NB/deg ist außer Haus.
Ich werde ab 26.09.2005 nicht im Büro sein. Ich kehre zurück am 10.10.2005.
Re: This week on harmony-dev (Sept. 18 - Sept. 24 2005)
On Mon, 2005-09-26 at 10:00 +0100, Tim Ellison wrote: David Tanzer wrote: Later this week, Rodrigo Kumpera contributed a JVM he has written in Java. ... AFAIK Rodrigo hasn't contributed his VM (yet), but made a generous offer [1] to donate if is desirable. I'd say that it *is* desirable to have Rodrigo's contribution as the seed for a Java-based VM study. You are right, thank you for this hint. I have corrected it in the blog. Regards, David Of course, since the summary was written we also got a contribution from archie [2] of key parts of the JCVM (= JCHE). Regards, Tim [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky: Narf! Pinky: Poit! Pinky: Zort! Pinky: Gat! signature.asc Description: This is a digitally signed message part
Re: [arch] VMCore / Component Model
I have now added the prototype implementation to JIRA: http://issues.apache.org/jira/browse/HARMONY-5 Cheers, David. On Mon, 2005-09-19 at 19:46 +0200, David Tanzer wrote: Today I have added some additional Information to the Wiki page. We should also consider using C++ and abstract classes to maintain our component model. While this would make inter-component communication slightly slower it would be easier to maintain. We should also think about using an existing component model like OSGi. The model I posted provides pretty fast communication between components without sacrificing too much flexibility, but it is maybe not as easy to maintain as a clean, object-oriented implementation (i.e. C++). We could discuss how important these aspects are to us, i.e. how much runtime efficiency we are willing to sacrifice for maintainability and flexibility and vice-versa. Regards, David. On Fri, 2005-09-16 at 21:47 +0200, David Tanzer wrote: Ok, it took a little bit longer than I first expected, but now my proof-of-concept implementation of the component model I described is available in the wiki: http://wiki.apache.org/harmony/ComponentModelFunctionPointers I have also linked it from the harmony architecture page. It contains a mechanism for loading components and a basic versioning and dependency management mechanism. The test case loads two components, where one depends on the other. I'll add some more explanations to the wiki page when I have more time, hopefully at the weekend. I have made several assumptions about the directory structure, the coding conventions and the documentation conventions, we should maybe discuss this in a different thread. Regards, David. On Tue, 2005-09-13 at 17:27 +0100, Tim Ellison wrote: David Tanzer wrote: Since we already started to define some component interfaces I think we also should start thinking about a component model which loads / connects such components. Maybe there are also some existing solutions we might want to look at (I must confess I didn't really search yet). Agreed, plus managing the API itself to ensure forwards/backwards version compatibility. I guess a requirement for such a component manager would be that it can load and connect components at runtime and that the specific implementations which are loaded can be configured. It might also be good if the same component implementations can be linked at compile time (i.e. statically) which could have benefits on embedded platforms, but I'm not sure if we really need this. I'm assuming that you are speculating on component management beyond the platform support (i.e. DLL-hell). The java world is already on this path with the OSGi framework (e.g. Felix). It will require a non-trivial solution to ensure that the runtime flexibility does not incur an unacceptable runtime cost. Another requirement would be that the components can be written in different programming languages (i.e. C, C++, Java, ...). It isn't really a problem to solve this for C and C++, but can we also easily support other programming languages? A simple way to implement such a component model in C would be an approach similar to the one Tim Ellison described in [1] where he explains the structure of the J9 VM's portability library. I started writing a proof of concept implementation for this, and I'll add it to the wiki as soon as it's finished. I look forward to seeing the proof of concept. Were you thinking of introducing versioning and dependency management style functions? It would be interesting to have several such proof-of-concept implementations of component models which we can study and the decide which to use. We could even write import mechanisms for the different component models so they can import and use components from another model too (of course this would normally imply reduced performance). Regards, David. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Brain: Pinky, I am in considerable pain. Pinky: Narf! Zort! Poit! Gat! I'm with you, Brain! -- Twas the Day Before Christmas signature.asc Description: This is a digitally signed message part
Re: [arch] VMCore / Component Model
Excellent - thanks On Sep 26, 2005, at 2:23 PM, David Tanzer wrote: I have now added the prototype implementation to JIRA: http://issues.apache.org/jira/browse/HARMONY-5 Cheers, David. On Mon, 2005-09-19 at 19:46 +0200, David Tanzer wrote: Today I have added some additional Information to the Wiki page. We should also consider using C++ and abstract classes to maintain our component model. While this would make inter-component communication slightly slower it would be easier to maintain. We should also think about using an existing component model like OSGi. The model I posted provides pretty fast communication between components without sacrificing too much flexibility, but it is maybe not as easy to maintain as a clean, object-oriented implementation (i.e. C++). We could discuss how important these aspects are to us, i.e. how much runtime efficiency we are willing to sacrifice for maintainability and flexibility and vice-versa. Regards, David. On Fri, 2005-09-16 at 21:47 +0200, David Tanzer wrote: Ok, it took a little bit longer than I first expected, but now my proof-of-concept implementation of the component model I described is available in the wiki: http://wiki.apache.org/harmony/ComponentModelFunctionPointers I have also linked it from the harmony architecture page. It contains a mechanism for loading components and a basic versioning and dependency management mechanism. The test case loads two components, where one depends on the other. I'll add some more explanations to the wiki page when I have more time, hopefully at the weekend. I have made several assumptions about the directory structure, the coding conventions and the documentation conventions, we should maybe discuss this in a different thread. Regards, David. On Tue, 2005-09-13 at 17:27 +0100, Tim Ellison wrote: David Tanzer wrote: Since we already started to define some component interfaces I think we also should start thinking about a component model which loads / connects such components. Maybe there are also some existing solutions we might want to look at (I must confess I didn't really search yet). Agreed, plus managing the API itself to ensure forwards/backwards version compatibility. I guess a requirement for such a component manager would be that it can load and connect components at runtime and that the specific implementations which are loaded can be configured. It might also be good if the same component implementations can be linked at compile time (i.e. statically) which could have benefits on embedded platforms, but I'm not sure if we really need this. I'm assuming that you are speculating on component management beyond the platform support (i.e. DLL-hell). The java world is already on this path with the OSGi framework (e.g. Felix). It will require a non- trivial solution to ensure that the runtime flexibility does not incur an unacceptable runtime cost. Another requirement would be that the components can be written in different programming languages (i.e. C, C++, Java, ...). It isn't really a problem to solve this for C and C++, but can we also easily support other programming languages? A simple way to implement such a component model in C would be an approach similar to the one Tim Ellison described in [1] where he explains the structure of the J9 VM's portability library. I started writing a proof of concept implementation for this, and I'll add it to the wiki as soon as it's finished. I look forward to seeing the proof of concept. Were you thinking of introducing versioning and dependency management style functions? It would be interesting to have several such proof-of-concept implementations of component models which we can study and the decide which to use. We could even write import mechanisms for the different component models so they can import and use components from another model too (of course this would normally imply reduced performance). Regards, David. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ 200509.mbox/[EMAIL PROTECTED] -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Brain: Pinky, I am in considerable pain. Pinky: Narf! Zort! Poit! Gat! I'm with you, Brain! -- Twas the Day Before Christmas -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
