sorry, mike!
in a 3 minute examination of apache tuscany it seems like there are some
similar aims and some overlap in capability. both are addressing SOA
issues such as protocol independence and implementation independence.
both seek to make deploying service oriented architectures a snap. the
two approaches are definitely distinct and many important aims of one
are not addressed by the other. there is likely some interesting synergy
possible down the road.
scott out
Mike Edwards wrote:
Scott,
I don't think that my question was answered.
I want to make it clear: I have no issues with names.
Yours, Mike.
scott comer wrote:
the discussion about names seems somewhat done. it is easy to get the
impression from the volume that there is a demand for name change. in
my opinion there isn't. certainly names is a rich topic and the
discussion
would never die down on it's own because it is so much fun. it's a
wonder
anything gets done...
here is a summary of who's responded to our proposal and an indication
of the topic.
[EMAIL PROTECTED] +1
[EMAIL PROTECTED] +1 (MENTOR)
[EMAIL PROTECTED] +1 (TOOMANY, NAME)
[EMAIL PROTECTED] +1 (NAME)
[EMAIL PROTECTED] +1 (TOOGOOD, TOOMANY, NAME, MENTOR)
[EMAIL PROTECTED] +1
[EMAIL PROTECTED] +1 (TOOMANY, MENTOR)
[EMAIL PROTECTED] (TOOMANY)
[EMAIL PROTECTED] (NAME)
[EMAIL PROTECTED] (QUESTION)
[EMAIL PROTECTED] (NAME)
[EMAIL PROTECTED] (NAME)
[EMAIL PROTECTED] (NAME)
[EMAIL PROTECTED] (TOOMANY)
[EMAIL PROTECTED] (TOOMANY)
[EMAIL PROTECTED] (NAME)
of the people that mention name (8), only 3 are voting:
henning: concerned about confusion with debian. only says we need to
be careful and explicit.
niall: wants to see the q resolved. likes the name, sees no real
objection.
niclas: conflict with debian; only worries about it.
of the rest, most like the name etch and seem to be just "tossing the
ball around".
the main other concern is that of confusion with Debian Etch vs.
Apache Etch. There
was some discussion about whether etch could get to the top of the
google list.
so, can we put the name question to bed? it was suggested that the
podling could/should
decide the issue for itself, later. is there a problem with that?
are there any other concerns about the proposal which aren't addressed?
scott out
---------------------------------------------------------------------
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]