Hi Bela, since the original email was with legal, I better make it
public on the tomcat dev list.
no worries, this implementation is more different than JGroups than
other groupcomm frameworks, like Appia for example
(http://appia.di.fc.ul.pt/ http://appia.di.fc.ul.pt/docs/javadoc/,
changing license to ASF). Appia uses events, gossip, channel, etc. I
think you will find more similarities in the design with Appia than with
Tribes.
we don't have a Message class, but the words Channel, ChannelException
and ChannelListener, are hardly unique to JGroups, besides, the are way
different implementation, so the words used are hardly an issue.
Tribes uses a thread less interceptor chain, and then is built very
differently at the messaging layer.
The goal of tribes is the opposite of JGroups, JGroups strives for the
uniform model when Tribes is built for replication, and doesn't striv
for uniformity. The goals for Tribes are to support messaging in
heterogeneous clusters, with per message sending attributes, something
that JGroups doesn't have.
I'm not worried about the similarities, but if you are, you should
persue other frameworks, who have built their stuff after reading the
same books (K.P Birman) as are the foundation for JGroups, as Tribes
doesn't have the ambitions for that.
And I believe that IP for uniform groupcomm, existed way before JGroups.
So to summarize,
1. There is nothing unique about the names used in different group comm
frameworks.
2. There is no code copied from JGroups
3. There are many other frameworks that use more similarities than
Tribes, hence better targets for legal action, if such exists
4. Tribes is a heterogenous cluster communication framework, JGroups
strives to be a uniform group comm framework.
5. Tribes has a very different design, so its not even a
re-implementation, its a brand new framework built on new ideas on how
to improve comm in hetergeneous clusters, not in a uniform model.
6. The ideas for JGroups are not unique, and there are many frameworks
that do the same.
7. The further the developement of tribes goes, the further apart they
will probably go
8. If you find IP in Tribes that could be very useful in JGroups, feel
free to use it, I believe it has some strong advantages, and we would
not be threatened if you took advantage of some of the stuff that we have.
Tribes is built with unordered data replication in mind, and supports
concurrent messaging in highly concurrent environments. Very different
from JGroups. Tribes has never been close to the JGroups implementation,
and doesn't aim for that either. And the idea of a thread less and RPC
like stack I believe is my IP :)
Please let us know if this doesn't clarify how different these two
frameworks are different, and if JBoss is concerned with IP or
similarities, then can raise the questions to us, but we would like to
advise that there are more implementations out of the same books/papers
that JGroups came from, that are probably better targets.
Feel free to borrow ideas from here, the Open Source community can only
benefit from it.
Filip
Bela Ban wrote:
Hi Filip, Peter,
I found the following stuff in
tomcat/container/tc5.5.x/modules/groupcomm/src/share/org.apache.catalina.tribes:
* Channel, ChannelException, ChannelListener, MembershipListener,
MessageListener, Message: these have exactly the same names as the
JGroups equivalent, but are a re-implementation
* tipis: ReplicatedMap (JGroups ReplicatedHashtable), RpcChannel
(RpcDispatcher),
* group.interceptors: FragmentationInterceptor (FRAG, FRAG2),
OrderInterceptor (NAKACK)
etc etc
These classes are not copies of their equivalent JGroups classes, but
they are reimplementations of the same ideas *under ASL*.
So it looks like you guys are reimplementing JGroups under an Apache
license. This is fine as long as you're not copying JGroups code and
re-license it under an Apache license. Also note that IP includes
ideas as well, so I would advise you not to stay too close to the
original implementation.
This is not a threat by all means, but I wanted to make you aware of
this.
Cheers,
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
