You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by James Carman <ja...@carmanconsulting.com> on 2005/09/21 05:43:17 UTC
[discuss] 1.2 Roadmap?
What do we want to accomplish with the 1.2 release?
Re: [discuss] 1.2 Roadmap?
Posted by Achim Hügen <ac...@gmx.de>.
I'd like to work on
- improved documentation
- reusable dependency injection, that is the possibility
to autowire objects which are not managed by hivemind
Achim
Am Wed, 21 Sep 2005 05:43:17 +0200 schrieb James Carman
<ja...@carmanconsulting.com>:
> What do we want to accomplish with the 1.2 release?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: [discuss] 1.2 Roadmap?
Posted by Davor Hrg <hr...@gmail.com>.
A way to reuse schema would be great for composing
complex schema-s recursively, maybe even recursion limit
to ensure more sane usage.
On 9/23/05, Massimo Lusetti <ml...@gmail.com> wrote:
>
> On 9/21/05, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> > I want to pursue the idea of doing more of the service construction in
> > non-reflective code.
>
> That would be great and was absolutely my first issue/thought about
> hivemind in general.
>
> > I want to see descriptors that allow Spring code to be used as native
> > HiveMInd services.
>
> If i may express my preferences this would definetly be the first
> point ever. I could remember someone (maybe Howard) spoke about
> HiveMind as a framework for building framework or something like that
> while Spring as a framework for building final apps. I completely
> agree with that statement and think having hiveMind open and easy
> interaction with spring could boost it adoption a lot.
> Are you thinking of a specific service model with its own life cycle?
>
> --
> Massimo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
Re: [discuss] 1.2 Roadmap?
Posted by Massimo Lusetti <ml...@gmail.com>.
On 9/21/05, Howard Lewis Ship <hl...@gmail.com> wrote:
> I want to pursue the idea of doing more of the service construction in
> non-reflective code.
That would be great and was absolutely my first issue/thought about
hivemind in general.
> I want to see descriptors that allow Spring code to be used as native
> HiveMInd services.
If i may express my preferences this would definetly be the first
point ever. I could remember someone (maybe Howard) spoke about
HiveMind as a framework for building framework or something like that
while Spring as a framework for building final apps. I completely
agree with that statement and think having hiveMind open and easy
interaction with spring could boost it adoption a lot.
Are you thinking of a specific service model with its own life cycle?
--
Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: [discuss] 1.2 Roadmap?
Posted by Knut Wannheden <kn...@gmail.com>.
On 9/21/05, Howard Lewis Ship <hl...@gmail.com> wrote:
> I want to pursue the idea of doing more of the service construction in
> non-reflective code.
>
> So, a module will be able to delegate to a class, and that class will
> be used instead of a ServiceImplementationFactory to build services;
> there will be a naming convention used to define what services are
> defined in the module class (vs. in the XML).
>
(I just reread your original proposal and the discussion about this:
http://thread.gmane.org/gmane.comp.jakarta.hivemind.devel/1388) As I
understand this idea, this would allow me to define a module using a
Java class instead of an XML descriptor. This would indeed be quite
nice! Although I believe we would need an API which both the XML
parser and this new "Java parser" used to register the module (and
it's contents) with the registry. I spent some time to outline a
proposal for this API on the Wiki:
http://wiki.apache.org/jakarta-hivemind/DescriptorApiRevampProposal.
Did someone get time to look at this?
> I'm hoping this will help speed application startup. Tapestry 4.0 is
> too slow to start.
>
> I'd like to look elsewhere for other speedups; perhaps a custom Map
> implementation tuned for small numbers of elements.
>
Sounds interesting. Have you run a HiveMind application through a profiler?
> Annoations would be nice, but I think we want to keep
> HiveMind/Tapestry useable with JDK 1.3 for a while longer ...
> something to discuss. Perhaps JDK 1.4 so we could ditch ORO.
>
The annotions could be optional, no? IMHO moving to JDK 1.4 would be a
good thing.
> I'd like to see a replacement for BuilderFactory called
> "InjectionFactory" that uses significantly streamlined XML.
>
+1
> I want to be able to use a Schema to parse an arbitrary XML stream.
>
Would this result in configuration contributions or what's the usecase?
> I want to see descriptors that allow Spring code to be used as native
> HiveMInd services.
>
That would be nice. Do you think it could involve some Java coding to
make the services more HiveMind like? Where would we host these
descriptors?
> I'd like to (expirement with) caching the contents of XML descriptors
> on the file system so that restarts of an application are faster.
>
Also sounds interesting.
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: [discuss] 1.2 Roadmap?
Posted by James Carman <ja...@carmanconsulting.com>.
One of the main gripes with HiveMind is the XML aspect of it (the "less XML
is good"). I would like for us to try to make it easy to build a registry
via code.
-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: Wednesday, September 21, 2005 3:14 PM
To: hivemind-dev@jakarta.apache.org
Subject: Re: [discuss] 1.2 Roadmap?
I want to pursue the idea of doing more of the service construction in
non-reflective code.
So, a module will be able to delegate to a class, and that class will
be used instead of a ServiceImplementationFactory to build services;
there will be a naming convention used to define what services are
defined in the module class (vs. in the XML).
I'm hoping this will help speed application startup. Tapestry 4.0 is
too slow to start.
I'd like to look elsewhere for other speedups; perhaps a custom Map
implementation tuned for small numbers of elements.
Annoations would be nice, but I think we want to keep
HiveMind/Tapestry useable with JDK 1.3 for a while longer ...
something to discuss. Perhaps JDK 1.4 so we could ditch ORO.
I'd like to see a replacement for BuilderFactory called
"InjectionFactory" that uses significantly streamlined XML.
I want to be able to use a Schema to parse an arbitrary XML stream.
I want to see descriptors that allow Spring code to be used as native
HiveMInd services.
I'd like to (expirement with) caching the contents of XML descriptors
on the file system so that restarts of an application are faster.
On 9/21/05, David J. M. Karlsen <da...@davidkarlsen.com> wrote:
> James Carman wrote:
> > What do we want to accomplish with the 1.2 release?
> >
> Thorough and consistent documentation. I really think this would help on
> HiveMind's popularity.
>
> --
> David J. M. Karlsen - +47 90 68 22 43
> http://www.davidkarlsen.com
> http://mp3.davidkarlsen.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: [discuss] 1.2 Roadmap?
Posted by Howard Lewis Ship <hl...@gmail.com>.
I want to pursue the idea of doing more of the service construction in
non-reflective code.
So, a module will be able to delegate to a class, and that class will
be used instead of a ServiceImplementationFactory to build services;
there will be a naming convention used to define what services are
defined in the module class (vs. in the XML).
I'm hoping this will help speed application startup. Tapestry 4.0 is
too slow to start.
I'd like to look elsewhere for other speedups; perhaps a custom Map
implementation tuned for small numbers of elements.
Annoations would be nice, but I think we want to keep
HiveMind/Tapestry useable with JDK 1.3 for a while longer ...
something to discuss. Perhaps JDK 1.4 so we could ditch ORO.
I'd like to see a replacement for BuilderFactory called
"InjectionFactory" that uses significantly streamlined XML.
I want to be able to use a Schema to parse an arbitrary XML stream.
I want to see descriptors that allow Spring code to be used as native
HiveMInd services.
I'd like to (expirement with) caching the contents of XML descriptors
on the file system so that restarts of an application are faster.
On 9/21/05, David J. M. Karlsen <da...@davidkarlsen.com> wrote:
> James Carman wrote:
> > What do we want to accomplish with the 1.2 release?
> >
> Thorough and consistent documentation. I really think this would help on
> HiveMind's popularity.
>
> --
> David J. M. Karlsen - +47 90 68 22 43
> http://www.davidkarlsen.com
> http://mp3.davidkarlsen.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: [discuss] 1.2 Roadmap?
Posted by "David J. M. Karlsen" <da...@davidkarlsen.com>.
James Carman wrote:
> What do we want to accomplish with the 1.2 release?
>
Thorough and consistent documentation. I really think this would help on
HiveMind's popularity.
--
David J. M. Karlsen - +47 90 68 22 43
http://www.davidkarlsen.com
http://mp3.davidkarlsen.com
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: [discuss] 1.2 Roadmap?
Posted by Belaran <be...@gmail.com>.
Lifecycle model are clearly a great asset for HM, adding new model or
building tools or functionnalities for it, seems definitly a good approach.
As what to do next, filling this webpage could be a good idea : )
http://wiki.apache.org/jakarta-hivemind/RoadMap
RoadMap<http://wiki.apache.org/jakarta-hivemind/RoadMap?action=fullsearch&value=linkto%3A%22RoadMap%22&context=180>
*This page does not exist yet. You can create a new empty page, or use one
of the page templates. Before creating the page, please check if a similar
page already exists.*
Having a clear and defined roadmap will reassures companies who wish to use
HiveMind. It's neither dev neither fun but could be usefull...
I didn't look carefully the last version of hivemind but i believe there is
still nothing about the use of the version number of a module ?
To build HiveDoc you still need to use the Ant-task, I believed that the
sooner we HiveMind improve this tools ( auto build of HiveDoc at launch) the
better it will be.
That's my 2c.
2005/9/21, Jean-Francois Poilpret <jf...@hcm.vnn.vn>:
>
> Why not start with some of the open RFE on Jira.
>
> I think several of them would be very good to have in next version.
>
> So I suggest we have a look at the list of RFE and put priorities to them.
>
> In addtion, there were also some interesting points in the outdated
> "TODO" list of the HiveMind website.
>
> Besides, new service models could be interesting to have (we have already
> talked about "real" pooled model (with more parameters) and an easy way to
> set extra parameters to service models.
>
> Finally, one new point (I think I will input a JIRA for that one) that I
> find would be interesting is a way to define the order in which services
> that implement ShutdownListener will be notified of registry shutdown. Or
> maybe a simple way that I had in mind would be to have 2 levels of shutdown,
> with 2 methods in the listener: one is called before actual shutdown, the
> other after actual shutdown: this would allow services that need to use
> other services at "cleanup" time not to call services that have already been
> shutdown!
>
> I encountered this problem in one of my developments:
>
> - I created an "AsynchroneousTaskPerformer" service which I want to be
> sure will perform all remaining tasks before shutdown. The problem is that
> these tasks may rely on services that cannot work after they have been
> shutdown.
>
> Cheers
>
> Jean-Francois
>
> ------------------------------
>
> *From:* James Carman [mailto:james@carmanconsulting.com]
> *Sent:* Wednesday, September 21, 2005 10:43 AM
> *To:* hivemind-dev@jakarta.apache.org
> *Subject:* [discuss] 1.2 Roadmap?
>
> What do we want to accomplish with the 1.2 release?
>
--
Belaran,
"What'do'ya mean ?"
"As a motto, I just avoid meaning anything..."
RE: [discuss] 1.2 Roadmap?
Posted by Jean-Francois Poilpret <jf...@hcm.vnn.vn>.
Why not start with some of the open RFE on Jira.
I think several of them would be very good to have in next version.
So I suggest we have a look at the list of RFE and put priorities to them.
In addtion, there were also some interesting points in the outdated "TODO"
list of the HiveMind website.
Besides, new service models could be interesting to have (we have already
talked about "real" pooled model (with more parameters) and an easy way to
set extra parameters to service models.
Finally, one new point (I think I will input a JIRA for that one) that I
find would be interesting is a way to define the order in which services
that implement ShutdownListener will be notified of registry shutdown. Or
maybe a simple way that I had in mind would be to have 2 levels of shutdown,
with 2 methods in the listener: one is called before actual shutdown, the
other after actual shutdown: this would allow services that need to use
other services at "cleanup" time not to call services that have already been
shutdown!
I encountered this problem in one of my developments:
- I created an "AsynchroneousTaskPerformer" service which I want to be sure
will perform all remaining tasks before shutdown. The problem is that these
tasks may rely on services that cannot work after they have been shutdown.
Cheers
Jean-Francois
_____
From: James Carman [mailto:james@carmanconsulting.com]
Sent: Wednesday, September 21, 2005 10:43 AM
To: hivemind-dev@jakarta.apache.org
Subject: [discuss] 1.2 Roadmap?
What do we want to accomplish with the 1.2 release?