Re: [Proposal] HiveMind Service Framework

2003-11-12 Thread Henning Schmiedehausen
I still ask myself why we can't put HiveMind as its own project under
the Jakarta umbrella.

We have projects with a much smaller scope as normal jakarta projects
and we have and had framework projects such as Cocoon, Avalon or Turbine
outside of the commons.

IMHO the scope of HiveMind is already to big for the commons which I see
as software snacks: Small, easy to swallow and a side order for larger
projects.

Regards
Henning


On Tue, 2003-11-11 at 20:23, Martin Cooper wrote:
 Accepting this proposal as currently written would also involve the
 acceptance of five new individuals as Apache committers. Based on where
 the HiveMind repo currently is/was, that implies giving five unknowns (to
 me, anyway) access to Jakarta Commons as a whole. I'm not so sure I'd be
 willing to sign up for that.
 
 --
 Martin Cooper
 
 
  On Tue, 11 Nov 2003, Nayak, Prashant wrote:
 
 
  Proposal for the HiveMind Project
 
  (0) Rationale
 
  HiveMind is a simple framework for creating pluggable, configurable,
  reusable services.
 
  Simple: HiveMind is a way to create a network of services in terms of
  Java interfaces and classes; it cherry picks the most useful ideas from
  Service Oriented Architectures such as J2EE, JMX and SOAP, but removes
  the aspects that are typically overkill for most applications, such as
  service remoteability and language neutrality. HiveMind creates a
  natural network of related services and configuration data, all
  operating within a single JVM.
 
  Pluggable: HiveMind enforces a complete separation of service definition
  and implementation. This is manifested by a division of services into an
  interface definition and a service implementation as well as a split
  between defining a service (as part of a HiveMind module) and providing
  the implementation of that service (potentially, in a different module).
 
  Configurable: HiveMind integrates a service oriented architecture to a
  sophisticated configuration architecture; the configuration architecture
  is adapted from the Eclipse plug-in model, wherein modules may define
  configuration extension points and multiple modules may provide
  contributions to those extension points.
 
  Reusable: HiveMind is a framework and container, but not an application.
  The HiveMind framework and the services it provides may be easily
  combined with application-specific services and configurations for use
  in disparate applications.
 
  The API for HiveMind allows thread-safe, easy access to services and
  configurations with a minimal amount of code. The value-add for HiveMind
  is not just runtime flexibility: it is overall developer productivity.
  HiveMind systems will entail less code; key functionality that is
  frequently an after-thought, such as parsing of XML configuration files,
  logging of method invocations, and lazy creation of services, is handled
  by the HiveMind framework in a consistent, robust, and well-documented
  manner.
 
  HiveMind fits into an area that partially overlaps the Apache Avalon
  project, with significant differences. HiveMind's concept of a
  distributed configuration is unique among the available service
  microkernel's (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is
  firmly rooted in a type-1 inversion of control pattern (whereby services
  must explicitly, in code, resolve dependencies between each other using
  a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and
  type-3 IoC, whereby the framework (acting as container) creates
  connections between services by setting properties of the services
  (type-2) or making use of particular constructors for the services
  (type-3).
 
  HiveMind represents a generous donation of code to the ASF by WebCT
  (http://www.webct.com). HiveMind originated from internal requirements
  for a flexible, loosely-coupled configuration management and services
  framework for WebCT's industry-leading flagship enterprise e-learning
  product, Vista. Several individuals in WebCT's research and development
  team in addition to Mr. Howard Lewis Ship contributed to the
  requirements and concepts behind HiveMind's current set of functionality
  including Martin Bayly, Diane Bennett, Bill Bilic, Michael Kerr,
  Prashant Nayak, Bill Richard and Ajay Sharda. HiveMind is already in use
  as a significant part of Vista.
 
  (1) Scope of the package
 
  The package shall entail a core framework JAR (containing essential
  classes and services), a standard library JAR (containing generically
  useful services), along with ancillary artifacts such as Maven plug-ins
  and, of course, documentation, all distributed under the Apache Software
  License.
 
  (1.1) Interaction with other packages
 
  HiveMind has dependencies on several standard commons packages,
  including: commons-lang, commons-beanutils, commons-collections and
  commons-logging.
 
  HiveMind makes use of the Javassist bytecode generation library, which
  is available 

Re: BSD style code and licensing issues

2003-11-12 Thread Henning Schmiedehausen

On Tue, 2003-11-11 at 16:20, Mark R. Diggory wrote:
 That last thread seemed such a waste of bandwidth. Unfortunately it 
 swallowed a discussion we were trying to start concerning Licensing 
 issues associated with the consideration of using BSD style licensed 
 code in Apache Projects.
 
 To formulate a more solid point people can respond to:
 
 Can BSD licensed code be added to Apache licensed code bases? Can both 
 licenses be maintained? If so can someone direct me to an example of this?


You should read LKML for about six months or so. In this time, a
licensing discussion and a GPL is evil and maybe even a why binary
code is good/bad/don't care discussion as a bonus are due to happen
(The average brain of the net lasts six months).

As far as I can see:

BSD code inclusion in ASF code is ok, no strings attached, but there
should/must (depends on the BSD license) a notice which the original
copyright must be included with the source tree (or even when starting
the resulting program; some quite old BSD licenses required this, this
is why older AIX/HP-UX boxes displayed a plethora of copyright messages
when booting).

BTW: I just re-read this conglomerate of politics, ideology, crude
examples and pseudo-legal speech that calls itself LGPL
(http://www.opensource.org/licenses/lgpl-license.php).

IMHO, JBoss is in deep sh*t using this license:

- JBoss is not a library. But the JBoss Group insists that it is (which
  they seem to do, because they themselves declare JBoss to be one
  (they even link the web site cited above)

- If it is a library, then the whole § 2 applies. This basically means,
  that I can write an J2EE server by simply extending all the classes
  in the JBoss package (but e.g. calling it Foo J2EE Server) and
  putting a jboss binary distribution and a file that says:

  This product uses code from the JBoss application server with the
  appropriate copyright and a link to the JBoss source code repo.

- I can redistribute this in compiled (no source code at all) form
  (§5). 

I'd say that LGPL is for a language like Java (which has no concept of
linking) a pretty bad choice. In fact, I'd even look forward to JBoss
Group trying to prove its claims in court. I'm pretty sure that in the
end, the court will sack their own license and they (and all of their
customers) will suddenly have an unlicensed products. 

And, if JBoss is a library, then all programs running in the container
are suddently derived works. Which brings a whole new meaning to the
concept of linking _AND_ the legal issues of the licensing terms of
these programs!

ObDisc: IANAL, I just play one at late-night drinking contests.

Regards
Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

Außerdem können in Deutschland alle Englisch. [...] so entfällt die
Notwendigkeit [...] Deutsch zu lernen. 
-- Johan Micoud auf die Frage warum er kein Deutsch spricht.
   (http://www.spiegel.de/spiegel/0,1518,273205,00.html)




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Proposal] HiveMind Service Framework

2003-11-12 Thread Danny Angus




 I still ask myself why we can't put HiveMind as its own project under
 the Jakarta umbrella.

It doesn't seem unreasonable to me, if the criteria are met and the
political implications of creating a new sub-project are acceptable.
Otherwise a spell in commons will help to cement the community and do no
harm.

I would like to know if this has been proposed to Avalon, if not why not,
if so what has been their reaction.

I'm not suggesting that it should be, just that it might be a better fit
with their charter.

d.




***
The information in this e-mail is confidential and for use by the addressee(s) only. 
If you are not the intended recipient (or responsible for delivery of the message to 
the intended recipient) please notify us immediately on 0141 306 2050 and delete the 
message from your computer. You may not copy or forward it or use or disclose its 
contents to any other person. As Internet communications are capable of data 
corruption Student Loans Company Limited does not accept any  responsibility for 
changes made to this message after it was sent. For this reason it may be 
inappropriate to rely on advice or opinions contained in an e-mail without obtaining 
written confirmation of it. Neither Student Loans Company Limited or the sender 
accepts any liability or responsibility for viruses as it is your responsibility to 
scan attachments (if any). Opinions and views expressed in this e-mail are those of 
the sender and may not reflect the opinions and views of The Student Loans Company 
Limited.

This footnote also confirms that this email message has been swept for the presence of 
computer viruses.

**


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Call on Stein to resign over Gernimo

2003-11-12 Thread Geir Magnusson Jr .
On Tuesday, November 11, 2003, at 01:25 PM, Vic Cekvenich wrote:



Geir Magnusson Jr. wrote:

I think that this is the right list, very few people are intrested 
about the incubator. This is about ASF reputation. (It is also about 
the OSS reputation, including BSD, Linux, CodeHus, etc.)
Due to this Stein mistake OSS could be view as very lowest form. Makes 
me think ... hmm, did Linux developers refactor SCO code? Shame.

I would like to know... does ASF claim that if they refactor 
offending code one by one, they feel they are clean?
or
If the code was imported and beeing refactored, that that is a probelm.

Vic : I didn't write any of the above.  Please try and make clear your 
attributions especially when what you are saying is inflammatory and in 
the wrong forum.


The ASF treats the allegations of code copying very seriously, and 
will take what actions are necessary to ensure that no IP rights are 
violated, any offending code, if found, is removed, and any other 
appropriate action is taken.
I have been thinking about it, I do not think removing the offeding 
code  is appropriate or sufficient.

If proven, I think offending devlopers, new or old should be baned 
from ASF (and other OSS projects) for a few years. The project should 
be parked. Let it live on SF, why shield it (becuase now ASF has to 
use their lawyers/resources)

ASF should publicly applogize, and as a sign of friendship with OSS, 
do something to help jBoss, such as help with J2EE certification, or 
help with code or something.

Did I say that Stein should be removed, as the person out of all the 
OSS projects out there, did most to ruin the high reputation, trough 
negligence or some other reason.

I feel dirty using Apache Struts today becuase of this mess. I already 
remvoed ASF licnese from basicPortal.sf.net when this was originaly 
done and uses a commons license or something like that.

However, you must allow the alleged violations to be vetted - just as 
you wouldn't take the ASF's word that all was fine w/o explanation, 
you shouldn't take JBoss claim of violation at face value either.


http://theserverside.com/home/thread.jsp?thread_id=22337#101208
Above says:
The version 1.1 and 1.2 do contain an interface with methods hinting 
to the 3 maps design Marc is talking about. 

This is fine proof for me.

I think some sort of joint commission should be set up, of people with 
fine reputation, to report in a certain timeframe as to what happened.

Also a sepreare group should find out what to do about it.
This is a crissis as big as any, IMO.
To the people that are siting on the sidelines:
Do something. It does not have to be public.
It is when silent majority sits on the hands, and allows immoral 
things to happen that the society loses.
This is about sofware, not about lawyers.

I will try to make this last message on the topic of ethics, its up to 
the people sitting on the hands to see this is as a problem and do 
something.

.V



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [Proposal] HiveMind Service Framework

2003-11-12 Thread hlship
 On Wed, 12 Nov 2003, Henning Schmiedehausen wrote:
 
  I still ask myself why we can't put HiveMind as its own project under
  the Jakarta umbrella.
 
 Isn't that what this proposal is proposing?  If it isn't, then
 [EMAIL PROTECTED] is the wrong list to propose it to.
 
 
  We have projects with a much smaller scope as normal jakarta projects
  and we have and had framework projects such as Cocoon, Avalon or Turbine
  outside of the commons.
 
  IMHO the scope of HiveMind is already to big for the commons which I see
  as software snacks: Small, easy to swallow and a side order for larger
  projects.
 
 


Yes, this proposal is that HiveMind be a top-level Jakarta project; a peer to (say) 
Log4J and Tapestry.

The commons is largely supposed to be for toolboxes; libraries that contain individual 
utility classes (commons-lang) or frameworks with a very precise, very focused use 
(commons-logging). 

Although you could scavenge a lot of useful stuff out of HiveMind, it is intended for 
use as a cohesive unit.

In terms of homes, I can see a number of possible options:

1) Reject HiveMind outright --- and make Howard very sad.

In this case, I would reorganize the Tapestry build to accomidate having HiveMind as a 
sub-project (once the grants from WebCT come through). I feel that is less than ideal; 
despite the overlap, and evolution of ideas from Tapestry into HiveMind, I'd prefer to 
keep them seperate, with seperate teams.

2) Keep it in the commons

I have no real objection to this personally, but HiveMind doesn't quite fit with the 
commons charter, for the reasons discussed above (and in the commons charter).

3) Chuck it over to Avalon

I've looked to see how we could graft HiveMind into Avalon and vice-versa, but they 
are really quite different beasts.  The type-1 vs. type-2/type-3 split is intrinsic 
and difficult to reconcile.  HiveMind's concept of a module doesn't map so easily into 
the Avalon space, and HiveMind's free-for-all approach doesn't jive with Avalon's 
dogmatic security model (including its explicit application construction descriptor).

4) New TLD

I think HiveMind is a totally useful swiss-army knife that opens up the doors for a 
lot of really terrific approaches to solving common development problems. However, 
it's still a bit light to be a TLD ... something like 6600 NCLOC if memory serves 
(don't bet on it!).  Certainly if boil-the-ocean frameworks like Struts, Tapestry and 
Turbine aren't TLDs then HiveMind isn't either.

5) New Jakarta Project

As stated in the proposal; this is my preference.


--
[EMAIL PROTECTED]

Creator, Tapestry: Java Web 
Components
http://jakarta.apache.org/tapestry

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Proposal] HiveMind Service Framework

2003-11-12 Thread Danny Angus




Howard wrote:


 3) Chuck it over to Avalon

 I've looked to see how we could graft HiveMind into Avalon and
vice-versa,
 but they are really quite different beasts.  The type-1  vs.
type-2/type-3
 split is intrinsic and difficult to reconcile.  HiveMind's concept of a
module
 doesn't map so easily into the  Avalon space, and HiveMind's free-for-all
 approach doesn't jive with Avalon's dogmatic security model
 (including its explicit application construction descriptor).

I didn't mean to suggest that you should try to move avalon architecture
towards hivemind or vice versa,
but I did wonder if there would be support @avalon for an alternative
approach as an avalon sub-project.

The danger of having an Avalon alternative @jakarta is that it will be seen
by people as somehow being Jakarta's favoured solution, rather than as one
of two (or more) alternatives promoted by Avalon.
If you see what I mean.

Of course you went through this whole debate when we discussed whether we
needed Tapestry as an alternative to Struts, as equal members of Jakarta
neither approach can be seen to be in any way an endorsed or
favourite. The same (IMO) would not be true for service frameworks if
Hivemind was a Jakarta project not an Avalon one. Hivemind would be seen by
some to be Jakarta's favoured solution.

FWIW I'm certainly not going to oppose this, Hivemind seems to be a well
thought out proposal, but I don't want Jakarta to be accused of trying to
replace Avalon, and I guess that will mean involving Avalon folks in the
discussion.

Imagine the reaction there would be if I proposed a make utility as a
Jakarta sub-project, and perhaps you'll get the thrust of my concern.

d.



***
The information in this e-mail is confidential and for use by the addressee(s) only. 
If you are not the intended recipient (or responsible for delivery of the message to 
the intended recipient) please notify us immediately on 0141 306 2050 and delete the 
message from your computer. You may not copy or forward it or use or disclose its 
contents to any other person. As Internet communications are capable of data 
corruption Student Loans Company Limited does not accept any  responsibility for 
changes made to this message after it was sent. For this reason it may be 
inappropriate to rely on advice or opinions contained in an e-mail without obtaining 
written confirmation of it. Neither Student Loans Company Limited or the sender 
accepts any liability or responsibility for viruses as it is your responsibility to 
scan attachments (if any). Opinions and views expressed in this e-mail are those of 
the sender and may not reflect the opinions and views of The Student Loans Company 
Limited.

This footnote also confirms that this email message has been swept for the presence of 
computer viruses.

**


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Proposal] HiveMind Service Framework

2003-11-12 Thread J Aaron Farr
FYI:

   I think someone wanted this to get forwarded to the Avalon 'general' mailing
list, but since that doesn't exist, I thought I'd send it to our dev list. 

For the Avaloners:

There's been a bit of discussion lately on [EMAIL PROTECTED] about what to do with
Hivemind seeing that it has started to outgrow its current location in
commons-sandbox.  Some have suggested that it fits better over here in Avalon
(as a sub-project) than in Jakarta.  In some respects, I agree.  I think its a
little light to be its own top-level project (hivemind.apache.org) and if you
look at the jakarta charters vs avalon charters, Hivemind falls more on the
Avalon side of things.  Not sure what Howards thoughts are on that.


--- Danny Angus [EMAIL PROTECTED] wrote:
 
 
 
 
 Howard wrote:
 
 
  3) Chuck it over to Avalon
 
  I've looked to see how we could graft HiveMind into Avalon and vice-versa,
  but they are really quite different beasts.  The type-1  vs. type-2/type-3
  split is intrinsic and difficult to reconcile.  HiveMind's concept of a
  module doesn't map so easily into the  Avalon space, and HiveMind's
  free-for-all approach doesn't jive with Avalon's dogmatic security model
  (including its explicit application construction descriptor).
 
 I didn't mean to suggest that you should try to move avalon architecture
 towards hivemind or vice versa,
 but I did wonder if there would be support @avalon for an alternative
 approach as an avalon sub-project.
 
 The danger of having an Avalon alternative @jakarta is that it will be seen
 by people as somehow being Jakarta's favoured solution, rather than as one
 of two (or more) alternatives promoted by Avalon.
 If you see what I mean.
 
 Of course you went through this whole debate when we discussed whether we
 needed Tapestry as an alternative to Struts, as equal members of Jakarta
 neither approach can be seen to be in any way an endorsed or
 favourite. The same (IMO) would not be true for service frameworks if
 Hivemind was a Jakarta project not an Avalon one. Hivemind would be seen by
 some to be Jakarta's favoured solution.
 
 FWIW I'm certainly not going to oppose this, Hivemind seems to be a well
 thought out proposal, but I don't want Jakarta to be accused of trying to
 replace Avalon, and I guess that will mean involving Avalon folks in the
 discussion.
 
 Imagine the reaction there would be if I proposed a make utility as a
 Jakarta sub-project, and perhaps you'll get the thrust of my concern.
 
 d.

 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

---
  jaaron  http://jadetower.org

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Proposal] HiveMind Service Framework

2003-11-12 Thread Berin Loritsch
J Aaron Farr wrote:
FYI:

   I think someone wanted this to get forwarded to the Avalon 'general' mailing
list, but since that doesn't exist, I thought I'd send it to our dev list. 

For the Avaloners:

There's been a bit of discussion lately on [EMAIL PROTECTED] about what to do with
Hivemind seeing that it has started to outgrow its current location in
commons-sandbox.  Some have suggested that it fits better over here in Avalon
(as a sub-project) than in Jakarta.  In some respects, I agree.  I think its a
little light to be its own top-level project (hivemind.apache.org) and if you
look at the jakarta charters vs avalon charters, Hivemind falls more on the
Avalon side of things.  Not sure what Howards thoughts are on that.


Hmm.  The thing is if it is chucked over here, the whole Hivemind approach
will be factored toward the way we are doing things.  We only have so many
developers, and supporting something like this would be kind of a strain on our
resources.
Have the IP issues been sorted out with this package?  There are a whole host
of questions that we would need to sort out, PMC to PMC.  In the interest of
fairness, I think we should seriously talk about that in that capacity.  We
would, of course, include Howard in on the conversation.


--- Danny Angus [EMAIL PROTECTED] wrote:



Howard wrote:



3) Chuck it over to Avalon

I've looked to see how we could graft HiveMind into Avalon and vice-versa,
but they are really quite different beasts.  The type-1  vs. type-2/type-3
split is intrinsic and difficult to reconcile.  HiveMind's concept of a
module doesn't map so easily into the  Avalon space, and HiveMind's
free-for-all approach doesn't jive with Avalon's dogmatic security model
(including its explicit application construction descriptor).
I didn't mean to suggest that you should try to move avalon architecture
towards hivemind or vice versa,
but I did wonder if there would be support @avalon for an alternative
approach as an avalon sub-project.
The danger of having an Avalon alternative @jakarta is that it will be seen
by people as somehow being Jakarta's favoured solution, rather than as one
of two (or more) alternatives promoted by Avalon.
If you see what I mean.
Of course you went through this whole debate when we discussed whether we
needed Tapestry as an alternative to Struts, as equal members of Jakarta
neither approach can be seen to be in any way an endorsed or
favourite. The same (IMO) would not be true for service frameworks if
Hivemind was a Jakarta project not an Avalon one. Hivemind would be seen by
some to be Jakarta's favoured solution.
FWIW I'm certainly not going to oppose this, Hivemind seems to be a well
thought out proposal, but I don't want Jakarta to be accused of trying to
replace Avalon, and I guess that will mean involving Avalon folks in the
discussion.
Imagine the reaction there would be if I proposed a make utility as a
Jakarta sub-project, and perhaps you'll get the thrust of my concern.
d.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---
  jaaron  http://jadetower.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: [Proposal] HiveMind Service Framework

2003-11-12 Thread Noel J. Bergman
An article on The Server Side
(http://www.theserverside.com/home/thread.jsp?thread_id=22371) started me
thinking again about HiveMind today.  The major issues mentioned there are
the same as mentioned by Howard below:

  I've looked to see how we could graft HiveMind into Avalon and
vice-versa,
  but they are really quite different beasts.  The type-1 vs.
type-2/type-3
  split is intrinsic and difficult to reconcile.  HiveMind's concept of a
  module doesn't map so easily into the  Avalon space, and HiveMind's
  free-for-all approach doesn't jive with Avalon's dogmatic security model
  (including its explicit application construction descriptor).

Are these really incompatible concepts?  Isn't Merlin, for example, trying
to do more with auto-assembly?  Doesn't our model allow us to push services
to be used rather than having to pull them from a service manager?  I really
don't see why this is an either-or issue.

Likewise, free-for-all vs security can be viewed as a policy.

I suggest that people give some thought to how TO collaborate with HiveMind
and Avalon.  I think that the combination of people and technologies could
be great.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]