You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Alex Blewitt <Al...@ioshq.com> on 2003/08/07 12:10:36 UTC
Wiki pages/Project management?
I'm very interested in joining the Geronimo group. I've been toying
with the idea of writing a J2EE server for some time, so this is great
:-)
I've not had much experience in open-source projects, but I'm an
enthusiastic developer on Mac OS X and Java. I've got servers I can
test on Win 2k, Linux (Debian -- and I can help create a .deb package
for it) and Mac OS X. I've been working with Java since it came out in
'95, so I don't quite have the '10 years experience' that I've seen in
adverts, but it's close :-)
I've got some questions that I've not managed to find out in the
faq/info list:
o Is there a Wiki for discussions/project planning/management?
o How can I help and get involved with the design (or is it already
there?)
o What tasks need to be done and how can I help?
Alex.
RE: Central piece: to JMX or not to JMX - Avalon
Posted by "Noel J. Bergman" <no...@devtech.com>.
Alex,
> The FAQ from this point is:
> "Q: So is Geronimo going to be based on Avalon?
> A: To be certified Geronimo needs to fully support JMX and JNDI.
> ... etc ...
> I've already made a post to the effect of Geronimo isA JMX vs. Geronimo
> hasA JXM interface, and my preference is strongly for the latter.
> Has this decision already been taken to base it entirely on JMX ala
> JBoss? I really don't think that's the right way forward.
This community can make that decision as it puts together code. FWIW, I am
big on choice.
There is discussion about the next generation of Avalon having a model that
allows "container personalities", so a JMX personality would be a
possibility. Phoenix does have some support using MX4J.
I am cc'ing the Avalon folks to emphasize why this might be a good idea, but
it would be best of people interested in JMX support in an Avalon container
join dev@avalon.apache.org, and participate directly there.
--- Noel
RE: Central piece: to JMX or not to JMX - Avalon
Posted by "Noel J. Bergman" <no...@devtech.com>.
Alex,
Present opinion:
> My opinion was that a kick-ass J2EE container would probably not be
> built on JMX, but instead provide an interface for JMX access on
> top (instead of underneath).
Too many posts stop with an opinion. You did the right thing.
Reasoning, benefit, offer to test:
> My reasoning behind the JMX issue is that it forces the development
> down one particular path, with a lot of JMX-intermediary-layer
> messages being bounced between different components. Removing that
> layer, and having direct messaging instead is bound to be faster,
> though this is a subjective observation rather than having detailed
> analysis to back that up. I'll do some tests and report back.
Statement of compatibility:
> Although having a JMX interface is needed, it doesn't need to be based
> on JMX, in much the same way that in order to interoperate with CORBA
> it doesn't need to be built on top of CORBA.
You are arguing that you feel that JMX provides flexibility at the expense
of performance, and are offering to test that belief. Your hypothetical
alternative would be to provide a higher performance component model, with
JMX where necessary/useful. Is that about right?
And James is able to come back and suggest particular places in existing
code that is being donated, so that you can see how it is doing things, and
see if it addresses your technical issue (performance) in another way:
> Once the code is online, take a look at the interceptor stack and see
> what you think.
There are multiple ways to solve a problem. Also, there are various
desiderata, such as performance, flexibility, stability (of both the code
and the community), ease of use, standardization, etc., to be balanced.
Whether your hypothesis is right or wrong, presenting a hypothesis for
discussion, measurable benefits, showing compatibility with necessary
standards, and offering to evaluate whether or not your hypothesis is
correct is a good way to go. You learn, others learn, the focus is on
improvement, and everyone wins. :-)
--- Noel
Re: Central piece: to JMX or not to JMX - Avalon
Posted by James Strachan <ja...@yahoo.co.uk>.
Alex
Once the code is online, take a look at the interceptor stack and see
what you think.
On Thursday, August 7, 2003, at 03:29 pm, Alex Blewitt wrote:
>>> A: To be certified Geronimo needs to fully support JMX and JNDI. So
>>> the current plan is to follow the direction of Tomcat 5, Jetty &
>>> JBoss and to use MBeans to register & wire the services together
>>> along with JNDI.
>>>
>>> Has this decision already been taken to base it entirely on JMX ala
>>> JBoss?
>>
>> So far yes. Right now like Tomcat 5, Jetty & JBoss we're using the
>> JMX component model for the foreseeable future along with our own
>> lifecycle mechanism closely tied with the J2EE deployment &
>> classloader mechanisms. Just because another services framework
>> exists it doesn't mean we have to use it. Though things may change in
>> the future.
>
>> Remember our aim is to build a kick ass J2EE container - not reuse
>> every bit of code we can find.
>>
>>> I really don't think that's the right way forward.
>>
>> Thats a convincing argument :) Why? I wonder why Tomcat 5, JBoss &
>> Jetty haven't jumped on Avalon either. Until we get going over here
>> why not start there first then come back here later when we're a
>> little more up to speed & things are documented & described a little
>> better & you've managed to convince Tomcat, Jetty or JBoss to ditch
>> JMX and use Avalon instead?
>
> I ought to be clearer in my posts ;-) I didn't necessarily advocate
> Avalon over Xxx; that was in response to a previous post.
>
> What I was saying, and had made a post to before, was that I can't see
> why we should be basing it on JMX [just because that's how Tomcat 5,
> Jetty, JBoss uses]. My opinion was that a kick-ass J2EE container
> would probably not be built on JMX, but instead provide an interface
> for JMX access on top (instead of underneath).
>
> My reasoning behind the JMX issue is that it forces the development
> down one particular path, with a lot of JMX-intermediary-layer
> messages being bounced between different components. Removing that
> layer, and having direct messaging instead is bound to be faster,
> though this is a subjective observation rather than having detailed
> analysis to back that up. I'll do some tests and report back.
>
> Although having a JMX interface is needed, it doesn't need to be based
> on JMX, in much the same way that in order to interoperate with CORBA
> it doesn't need to be built on top of CORBA.
>
> These were the thoughts behind the original post, and the follow on
> from the Avalon post led me to the FAQ answer with the 'We are using
> JMX' answer, hence this query.
>
> Alex.
>
>
James
-------
http://radio.weblogs.com/0112098/
Re: Central piece: to JMX or not to JMX - Avalon
Posted by Alex Blewitt <Al...@bandlem.com>.
>> A: To be certified Geronimo needs to fully support JMX and JNDI. So
>> the current plan is to follow the direction of Tomcat 5, Jetty &
>> JBoss and to use MBeans to register & wire the services together
>> along with JNDI.
>>
>> Has this decision already been taken to base it entirely on JMX ala
>> JBoss?
>
> So far yes. Right now like Tomcat 5, Jetty & JBoss we're using the JMX
> component model for the foreseeable future along with our own
> lifecycle mechanism closely tied with the J2EE deployment &
> classloader mechanisms. Just because another services framework exists
> it doesn't mean we have to use it. Though things may change in the
> future.
> Remember our aim is to build a kick ass J2EE container - not reuse
> every bit of code we can find.
>
>> I really don't think that's the right way forward.
>
> Thats a convincing argument :) Why? I wonder why Tomcat 5, JBoss &
> Jetty haven't jumped on Avalon either. Until we get going over here
> why not start there first then come back here later when we're a
> little more up to speed & things are documented & described a little
> better & you've managed to convince Tomcat, Jetty or JBoss to ditch
> JMX and use Avalon instead?
I ought to be clearer in my posts ;-) I didn't necessarily advocate
Avalon over Xxx; that was in response to a previous post.
What I was saying, and had made a post to before, was that I can't see
why we should be basing it on JMX [just because that's how Tomcat 5,
Jetty, JBoss uses]. My opinion was that a kick-ass J2EE container would
probably not be built on JMX, but instead provide an interface for JMX
access on top (instead of underneath).
My reasoning behind the JMX issue is that it forces the development
down one particular path, with a lot of JMX-intermediary-layer messages
being bounced between different components. Removing that layer, and
having direct messaging instead is bound to be faster, though this is a
subjective observation rather than having detailed analysis to back
that up. I'll do some tests and report back.
Although having a JMX interface is needed, it doesn't need to be based
on JMX, in much the same way that in order to interoperate with CORBA
it doesn't need to be built on top of CORBA.
These were the thoughts behind the original post, and the follow on
from the Avalon post led me to the FAQ answer with the 'We are using
JMX' answer, hence this query.
Alex.
Re: Central piece: to JMX or not to JMX - Avalon
Posted by James Strachan <ja...@yahoo.co.uk>.
On Thursday, August 7, 2003, at 02:57 pm, Alex Blewitt wrote:
>>> I think using Avalon (or Phoenix) is a great idea and something we
>>> should look into.
>>
>> The initial contributors did look into this (see below).
>
> The FAQ from this point is:
>
> "Q: So is Geronimo going to be based on Avalon?
>
> A: To be certified Geronimo needs to fully support JMX and JNDI. So
> the current plan is to follow the direction of Tomcat 5, Jetty & JBoss
> and to use MBeans to register & wire the services together along with
> JNDI.
>
> There are a lot of different 'services frameworks' such as JMX,
> Avalon, PicoContainer?, Spread, Java Beans etc. The only one we
> absolutely must support is JMX - so we'll focus on that first. However
> there is no reason why Geronimo cannot have other kinds of containers
> dropped in as services (Avalon, PicoContainer? or whatever). From
> Geronmio's perspective its just a bunch of MBeans. "
>
> I think that although Geronimo needs to /support/ JMX and JNDI, it
> doesn't need to be /built/ in terms of JMX and JNDI. So it could (for
> example) be built on top of Avalon, and have JMX interfaces for the
> things that need it.
>
> I've already made a post to the effect of Geronimo isA JMX vs.
> Geronimo hasA JXM interface, and my preference is strongly for the
> latter.
>
> Has this decision already been taken to base it entirely on JMX ala
> JBoss?
So far yes. Right now like Tomcat 5, Jetty & JBoss we're using the JMX
component model for the foreseeable future along with our own lifecycle
mechanism closely tied with the J2EE deployment & classloader
mechanisms. Just because another services framework exists it doesn't
mean we have to use it. Though things may change in the future.
Please give us some time to find our feet & grow - at least let us get
CVS setup with the initial codebase before commenting on the code that
you've not seen yet :).
There are lots of things on our plate - but lets not dive in deciding
which frameworks should be reused before you've studied what we're
actually doing and so can make a considered judgment on the right thing
to do for Geronimo, the J2EE container (rather than Avalon).
Remember our aim is to build a kick ass J2EE container - not reuse
every bit of code we can find.
> I really don't think that's the right way forward.
Thats a convincing argument :) Why? I wonder why Tomcat 5, JBoss &
Jetty haven't jumped on Avalon either. Until we get going over here why
not start there first then come back here later when we're a little
more up to speed & things are documented & described a little better &
you've managed to convince Tomcat, Jetty or JBoss to ditch JMX and use
Avalon instead?
James
-------
http://radio.weblogs.com/0112098/
RE: Central piece: to JMX or not to JMX - Avalon
Posted by "Noel J. Bergman" <no...@devtech.com>.
Alex,
> The FAQ from this point is:
> "Q: So is Geronimo going to be based on Avalon?
> A: To be certified Geronimo needs to fully support JMX and JNDI.
> ... etc ...
> I've already made a post to the effect of Geronimo isA JMX vs. Geronimo
> hasA JXM interface, and my preference is strongly for the latter.
> Has this decision already been taken to base it entirely on JMX ala
> JBoss? I really don't think that's the right way forward.
This community can make that decision as it puts together code. FWIW, I am
big on choice.
There is discussion about the next generation of Avalon having a model that
allows "container personalities", so a JMX personality would be a
possibility. Phoenix does have some support using MX4J.
I am cc'ing the Avalon folks to emphasize why this might be a good idea, but
it would be best of people interested in JMX support in an Avalon container
join dev@avalon.apache.org, and participate directly there.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Central piece: to JMX or not to JMX - Avalon
Posted by Alex Blewitt <Al...@ioshq.com>.
>> I think using Avalon (or Phoenix) is a great idea and something we
>> should look into.
>
> The initial contributors did look into this (see below).
The FAQ from this point is:
"Q: So is Geronimo going to be based on Avalon?
A: To be certified Geronimo needs to fully support JMX and JNDI. So the
current plan is to follow the direction of Tomcat 5, Jetty & JBoss and
to use MBeans to register & wire the services together along with JNDI.
There are a lot of different 'services frameworks' such as JMX, Avalon,
PicoContainer?, Spread, Java Beans etc. The only one we absolutely must
support is JMX - so we'll focus on that first. However there is no
reason why Geronimo cannot have other kinds of containers dropped in as
services (Avalon, PicoContainer? or whatever). From Geronmio's
perspective its just a bunch of MBeans. "
I think that although Geronimo needs to /support/ JMX and JNDI, it
doesn't need to be /built/ in terms of JMX and JNDI. So it could (for
example) be built on top of Avalon, and have JMX interfaces for the
things that need it.
I've already made a post to the effect of Geronimo isA JMX vs. Geronimo
hasA JXM interface, and my preference is strongly for the latter.
Has this decision already been taken to base it entirely on JMX ala
JBoss? I really don't think that's the right way forward.
Alex.
Re: Central piece: to JMX or not to JMX - Avalon
Posted by James Strachan <ja...@yahoo.co.uk>.
On Thursday, August 7, 2003, at 02:02 pm, Jonathan Duty wrote:
> I think using Avalon (or Phoenix) is a great idea and something we
> should look into.
The initial contributors did look into this (see below).
> The Apache foundation has provided the world with
> this great framework architecture, why not use it and practice what we
> preach.
This has already come up several times already and we're not even 2
days old yet so I've posted a FAQ.
http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/FAQ
James
-------
http://radio.weblogs.com/0112098/
RE: Central piece: to JMX or not to JMX - Avalon
Posted by Jonathan Duty <jd...@jonandkerry.com>.
I think using Avalon (or Phoenix) is a great idea and something we
should look into. The Apache foundation has provided the world with
this great framework architecture, why not use it and practice what we
preach.
Just my thoughts,
Jonathan
Jonathan Duty
Software Developer - eWashtenaw
-----Original Message-----
From: Christian Trutz [mailto:chris@smilebase.org]
Sent: Thursday, August 07, 2003 7:48 AM
To: geronimo-dev@incubator.apache.org
Subject: Re: Central piece: to JMX or not to JMX
hi alex,
1+ for geronimo hasA JMX interface and not isA MBean
a proxy should be a good idea
should the Geronimo Kernel be something like Avalon??
(better something like Phoenix)
chris
Re: Central piece: to JMX or not to JMX
Posted by Christian Trutz <ch...@smilebase.org>.
hi alex,
1+ for geronimo hasA JMX interface and not isA MBean
a proxy should be a good idea
should the Geronimo Kernel be something like Avalon??
(better something like Phoenix)
chris
Re: how about maven?
Posted by Christian Trutz <ch...@smilebase.org>.
i mean of course EJB container ... :-)
chris
Re: Central piece: to JMX or not to JMX
Posted by Emmanuel Bernard <ep...@yahoo.fr>.
Alex Blewitt wrote:
> I don't believe that a J2EE server should be the /central/ piece,
> though it should obviously be a main piece.
>
> One approach would be to configure various services with JMX, which
> leads to the question: should components be built on top of JMX, or
> should an interface be provided to control via JMX? My preference
> would be (initially) for the latter; although projects like JBoss are
> built on top of JMX I'm not sure it's necessary (or even desirable) to
> depend on JMX directly. (ApacheJ2EE hasA JMX interface, not ApacheJ2EE
> isA JMX interface).
>
> I think a micro-kernel architecture for setting up the server and
> configuring the various pieces is probably a good idea though, and
> that should be the central piece. The other components can then sit on
> top of that:
>
> + GeronimoKernel
> |-- GeronimoJNDIService
> |-- GeronimoEJBContainer
> |-- GeronimoWebContainer (maybe an interface to plug in Tomcat etc)
> |-- GeronimoSecurityService
See the Geronimo and avalon thread,. The Geronimo Kernel you talk of
sounds like an avalon framework implementation
RE: Central piece: to JMX or not to JMX (HiveMind)
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
I've been incubating a third alternative (not JMX and not Avalon) that could play a part: HiveMind
http://jakarta.apache.org/commons/sandbox/hivemind
It's a services and configuration microkernel; a melange of ideas drawn from Eclipse plugins and
JMX.
I can see it being used to bootstrap an application server, configuring the large blocks (possibly,
Avalon components) that will ultimately host EJBs and other artifacts.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
> -----Original Message-----
> From: Alex Blewitt [mailto:Alex.Blewitt@bandlem.com]
> Sent: Thursday, August 07, 2003 7:36 AM
> To: Christian Trutz
> Cc: geronimo-dev@incubator.apache.org
> Subject: Re: Central piece: to JMX or not to JMX
>
>
> > I think a central piece of an
> > J2EE implementation should be the
> > EJB container and that should be the
> > first think to concentrate.
>
> I don't believe that a J2EE server should be the /central/ piece,
> though it should obviously be a main piece.
>
> One approach would be to configure various services with JMX, which
> leads to the question: should components be built on top of JMX, or
> should an interface be provided to control via JMX? My
> preference would
> be (initially) for the latter; although projects like JBoss are built
> on top of JMX I'm not sure it's necessary (or even desirable)
> to depend
> on JMX directly. (ApacheJ2EE hasA JMX interface, not
> ApacheJ2EE isA JMX
> interface).
>
> I think a micro-kernel architecture for setting up the server and
> configuring the various pieces is probably a good idea
> though, and that
> should be the central piece. The other components can then sit on top
> of that:
>
> + GeronimoKernel
> |-- GeronimoJNDIService
> |-- GeronimoEJBContainer
> |-- GeronimoWebContainer (maybe an interface to plug in Tomcat etc)
> |-- GeronimoSecurityService
>
> and so on.
>
> Alex.
>
Re: Central piece: to JMX or not to JMX
Posted by Alex Blewitt <Al...@bandlem.com>.
> I think a central piece of an
> J2EE implementation should be the
> EJB container and that should be the
> first think to concentrate.
I don't believe that a J2EE server should be the /central/ piece,
though it should obviously be a main piece.
One approach would be to configure various services with JMX, which
leads to the question: should components be built on top of JMX, or
should an interface be provided to control via JMX? My preference would
be (initially) for the latter; although projects like JBoss are built
on top of JMX I'm not sure it's necessary (or even desirable) to depend
on JMX directly. (ApacheJ2EE hasA JMX interface, not ApacheJ2EE isA JMX
interface).
I think a micro-kernel architecture for setting up the server and
configuring the various pieces is probably a good idea though, and that
should be the central piece. The other components can then sit on top
of that:
+ GeronimoKernel
|-- GeronimoJNDIService
|-- GeronimoEJBContainer
|-- GeronimoWebContainer (maybe an interface to plug in Tomcat etc)
|-- GeronimoSecurityService
and so on.
Alex.
Re: how about maven?
Posted by Christian Trutz <ch...@smilebase.org>.
On Thu, Aug 07, 2003 at 01:08:04PM +0200, Hubert Gregoire wrote:
> Hi,
>
> I just add a TODO list page on the Wiki pages to start a task dispaching
> of the tasks
hi hubert,
>
> http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE
>
a good idea, but let us wait for the first piece of code
(i am VERY curious)
recall meritocracy :-)
I think a central piece of an
J2EE implementation should be the
EBJ container and that should be the
first think to concentrate.
how about MX4J code, I see the code is
under License: Apache Software License
that a good thing :-)
I would be pleased in the future
connecting to the
Geronimo EJB container via MX4J
:-)
chris
> , any ideas are welcome
>
>
> hubert
>
> Christian Trutz wrote:
>
> >hi folks,
> >
> >how about using Maven as developement process??
> >
> >i also could be a tester for:
> >
> >FreeBSD (4.8) with patched jdk for my free box and linux jdk 1.3.1 and
> >1.4.1
> >PostgreSQL
> >
> >chris
> >
> >
> >
> >
>
>
Re: how about maven?
Posted by Hubert Gregoire <hu...@free.fr>.
Hi,
I just add a TODO list page on the Wiki pages to start a task dispaching
of the tasks
http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE
, any ideas are welcome
hubert
Christian Trutz wrote:
>hi folks,
>
>how about using Maven as developement process??
>
>i also could be a tester for:
>
>FreeBSD (4.8) with patched jdk for my free box and linux jdk 1.3.1 and 1.4.1
>PostgreSQL
>
>chris
>
>
>
>
Re: how about maven?
Posted by Hubert Gregoire <hu...@free.fr>.
Of course, I hope we will use ANT, MAVEN and JUNIT in our dev processes...
hubert
Christian Trutz wrote:
>hi folks,
>
>how about using Maven as developement process??
>
>i also could be a tester for:
>
>FreeBSD (4.8) with patched jdk for my free box and linux jdk 1.3.1 and 1.4.1
>PostgreSQL
>
>chris
>
>
>
>
Re: how about maven?
Posted by James Strachan <ja...@yahoo.co.uk>.
On Thursday, August 7, 2003, at 10:51 pm, Danny Angus wrote:
>> At the risk of giving poor Sam apoplexy, I think that of all projects,
>> Geronimo should use GUMP as well (not instead of!).
>
> +1
>
> I had the same thought as soon as I saw the announcement, not only
> would
> this test geronimo against its dependancies it would also enable
> geronimo
> development to be broken down into the asynchronous development of a
> number
> of discrete sub-projects dealing with different areas.
> I'm assuming that it is going to be impractical to have a huge number
> of
> people (judging by the offers of support) working simultaneously on a
> single
> big codebase..
As soon as this is checked in you'll see we've a modular hierarchical
build system of sub-modules - each with their own dependencies that can
be built independently - using Maven (or Ant) for 1 module or Maven (&
Reactor) for the whole tree.
James
-------
http://radio.weblogs.com/0112098/
RE: how about maven?
Posted by Danny Angus <da...@apache.org>.
> At the risk of giving poor Sam apoplexy, I think that of all projects,
> Geronimo should use GUMP as well (not instead of!).
+1
I had the same thought as soon as I saw the announcement, not only would
this test geronimo against its dependancies it would also enable geronimo
development to be broken down into the asynchronous development of a number
of discrete sub-projects dealing with different areas.
I'm assuming that it is going to be impractical to have a huge number of
people (judging by the offers of support) working simultaneously on a single
big codebase..
d.
Re: how about maven?
Posted by James Strachan <ja...@yahoo.co.uk>.
Agreed. I wonder has anyone got Maven and Gump to play nice together
yet?
On Thursday, August 7, 2003, at 10:31 pm, Noel J. Bergman wrote:
> Jason,
>
> At the risk of giving poor Sam apoplexy, I think that of all projects,
> Geronimo should use GUMP as well (not instead of!). GUMP is the
> continuous
> integration system here at Apache, and it basically does a continuous
> build
> of all registered projects based upon dependency. Since Geronimo has
> so
> many dependencies, it could well be worth getting early notification
> of any
> problems.
>
> --- Noel
>
>
James
-------
http://radio.weblogs.com/0112098/
RE: how about maven?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jason,
At the risk of giving poor Sam apoplexy, I think that of all projects,
Geronimo should use GUMP as well (not instead of!). GUMP is the continuous
integration system here at Apache, and it basically does a continuous build
of all registered projects based upon dependency. Since Geronimo has so
many dependencies, it could well be worth getting early notification of any
problems.
--- Noel
Re: how about maven?
Posted by Jason Dillon <ja...@coredevelopers.net>.
Maven will be used as the project build system for Geronimo. We are
working on getting a skeleton system up very soon.
--jason
On Thursday, August 7, 2003, at 05:28 PM, Christian Trutz wrote:
> hi folks,
>
> how about using Maven as developement process??
>
> i also could be a tester for:
>
> FreeBSD (4.8) with patched jdk for my free box and linux jdk 1.3.1 and
> 1.4.1
> PostgreSQL
>
> chris
>
how about maven?
Posted by Christian Trutz <ch...@smilebase.org>.
hi folks,
how about using Maven as developement process??
i also could be a tester for:
FreeBSD (4.8) with patched jdk for my free box and linux jdk 1.3.1 and 1.4.1
PostgreSQL
chris
RE: Wiki pages/Project management?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I've got some questions that I've not managed to find out in the
> faq/info list:
> o Is there a Wiki for discussions/project planning/management?
Just add pages. :-)
> o How can I help and get involved with the design (or is it already
there?)
> o What tasks need to be done and how can I help?
Things are only just getting started. There are donations of code, but
those are just starting points.
--- Noel