Re: Withdraw from Incubator or TLP status?
I think we have had projects "leave", back in the day, before we were structured like this. But thinking about a example, maybe they were sub-projects. It's worth noting that anyone is free to fork an Apache licenced project at any time, so there is some protection should the founders which to leave the foundation with their code. Trademarks would be different. D. On Tue, 5 Mar 2019, 6:27 am Justin Mclean, wrote: > > Hi, > > Is there a specific reason you ask this? > > > 1. In the incubation period, because of some special matters, is it also > entitled to voluntarily withdraw? > > Yes it usually called retiring (although podling don’t really retire) , > but some projects live on elsewhere (like GitHub). The existing ALv2 would > need to be honoured and the project may need to change it name from the > Apache one, but it may not have to. See for example ODF Toolkit. > > > 2. After becoming a TLP, can this TLP still have the right to > voluntarily withdraw? > > An Apache project can be retired to the Attic. [1] After this development > could possibly occur elsewhere, but there may be naming and trademark > issues to consider. > > I would assume if a project asked the board to no longer be an Apache > project / podling they would consider it and probably wouldn’t want to keep > a project here against it’s will. I can’t recall this ever happening. > > Thanks, > Justin > > 1. https://attic.apache.org/process.html > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))
+1 If we trust mentors to ensure that their podling does the right thing as a board committee this basically *is* a TLP and we wouldn't need an IPMC, but if podlings need an IPMC then that must be because we allow for the podlings to make missteps without bringing down the hammer. Seems to me that simply explaining and teaching the principles that we are upholding, the purpose of the roles, and the reasons why we chose this mechanism to induct external projects would go a long way towards most of the specific points I have seen raised so far. D. On Mon, 4 Mar 2019, 6:19 am Greg Stein, wrote: > On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler wrote: > > > If a podling is a committee in its own right then it can be empowered to > > act on behalf of the board and this its releases can be an act of the > > foundation. > > > >... > > > Podlings would only become full TLPs once they have demonstrated their > > ability to do formal releases. > > > > The above pair of concepts was offered in $priorCycle as "provisional TLPs" > (pTLP). I believe the idea ended when Sam pointed out that if a pTLP is > trusted, then why not just call it a TLP and trust it to label its releases > appropriately? Thus, just create TLPs immediately for a "podling" > > [ I know Ross knows this; but for $others who may want to look at > historical proposals, and compare/contrast to current discussion ... search > for "pTLP" ] > > Cheers, > -g >
Re: log4php status?
We've been using log4php during development work, taking the next step on the road to production obviously depends upon the stability and future of the project. I'm reasonably comfortable with the way things work @apache, my question is really whether any of you think its more likely to fizzle out in the incubator or just take a long time to graduate? I could offer my help, but I may not have much help to offer. d. On Wed, Dec 17, 2008 at 3:32 PM, Jim Jagielski wrote: > Noel, > > I had forgotten to submit anything... basically, time got away > from me. > > log4php is slow... very slow. It is being used, but only occasionally > do we get bug reports, which are handled pretty quickly however. > > On Dec 15, 2008, at 11:31 AM, Noel J. Bergman wrote: > >> What is the status? See the Board report for what I culled from the >> mailing >> list and SVN, but we've not received a report from the project. >> >>--- Noel >> >> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Subversion vs other source control systems
On Thu, Feb 14, 2008 at 12:37 PM, Santiago Gala <[EMAIL PROTECTED]> wrote: > If I remember correctly, the policy was not to impose subversion, but to > mandate end of life for CVS. If I remember correctly, this was due to > security concerns, CVS requiring user accounts in the machine where the > repository is stored while subversion does not. Also functionality. Also > that having a lengthy transition was stressing infrastructure. I have > been looking into mail archives but have not found a pointer yet. That's also my recollection. ... > I don't think centralization has ever been part of "the Apache way". I think the cvs-svn experience, and the wiki experience, would suggest that we need to be mindful of the maintenance overhead of not centralising some practical things. But thats not the same as centralisation as a principle. And as a final point, don't take this too seriously but... the ASF and "the Apache Way" has probably been shaped more than we would like to admit by the workflow imposed by CVS. SVN is very similar, but distributed source control has very different workflow which would either conflict with or change "the way" if adopted. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WANTED: Another Mentor for QPid
On 5/14/07, Martin Ritchie <[EMAIL PROTECTED]> wrote: Hi, just wanted to keep this thread alive as it has been almost a month and we are still a mentor short. I just saw this, I'd be happy to serve if needed, FWIW I work in Glasgow so I have some degree of geographical proximity with the QPid guys. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: guides/graduation
Craig, [EMAIL PROTECTED] and [EMAIL PROTECTED] I think On 5/14/07, Craig L Russell <[EMAIL PROTECTED]> wrote: Now I'm confused. Could someone put some alias names to these concepts? I thought we were talking about -dev and - user. What aliases are others referring to? Thanks, Craig On May 14, 2007, at 1:19 PM, robert burrell donkin wrote: > On 5/14/07, Martin Sebor <[EMAIL PROTECTED]> wrote: >> Yoav Shapira wrote: >> > Hi, >> > >> > On 5/14/07, Craig L Russell <[EMAIL PROTECTED]> wrote: >> >> "The community mailing list is open to all Apache committers. >> This is >> >> the right list for >> >> questions about community and on community building. Subscriptions >> >> should be from an Apache email address." >> >> >> >> In my experience, the community mailing lists are open to everyone >> >> and it's not particularly useful to request that subscriptions be >> >> from an Apache email address. >> > >> > I like the last sentence. As a moderator for many ASF mailing >> lists, >> > having subscription requests from apache.org addresses make like >> a lot >> > easier. Please don't remove that last sentence ;) Since that >> > particular list is indeed open to the world, maybe a slight >> rephrasing >> > along the lines of "if you've got an Apache address, please use >> it to >> > subscribe" would be better. >> >> I can see how posts from apache.org might make the job of moderator >> of heavy list easier but shouldn't it be left up to each individual >> project to decide if they want to tighten the subscription policy? > > AIUI we're talking about the community mailing list which is an apache > wide list with no project affiliations > > - robert > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: counting downloads
On 5/2/07, Garrett Rooney <[EMAIL PROTECTED]> wrote: > Do other projects have a good way to track this? I know we could pull > the logs for the p.a.o webserver and grep through them looking for > things, but I'm wondering if there's something we can put on our > download page that users would click on that would count things? James uses google analytics. We currently count the hits to the download cgi page, which is probably over generous, but you can put google javascript on the links to the files themselves, we just haven't done it. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JiniProposal] Choosing a new name...
Hi Jim, I'd like to encourage you to avoid picking anything that is already a proper name, in other words an existing name which is normally capitalised in western languages. Using names which are already associated with people, places, events or cultures is never likely to be universally acceptable and on the whole is more likely to cause offence than to bring any lasting positive associations. For that reason I think that it is probably much easier if we avoid the issue altogether, and I know that choosing project names isn't easy but I'd ask you to add this consideration to the formula. d. On 22/09/06, Jim Hurley <[EMAIL PROTECTED]> wrote: As we're all too familiar with :-o -- picking a name (that everyone likes) is hard. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[policy] Ethics and Project Names - discuss
Hi, I think the time might be right to provoke a dispassionate discussion about our use of proper names for project names. I'd like to start by suggesting the following for discussion; That there be a new category of minimum exit requirements named somthing like "Ethical considerations" and that the initial item in this list be "The podling name should not equal or contain a proper noun which may already be associated with any identifiable community or individual or have a special meaning in any cultural context, unless such a proper noun is an attribution and is generally accepted to be relevant, such as the name of an inventor or associated institution." The intention is to discourage the use of proper names as project altogether, the exception is to allow the fine tradition of naming inventions after their inventor to continue. My reasoning for this is simple, the ASF has a high profile and we already know that some groups are unhappy with our use of the Apache name. I wouldn't suggest that we should re-name existing entities, but I do believe that adoption of a proper name and the high profile it will undobtedly receive by its association with the ASF is more likely to be met with disapproval, especially by groups to whom the name already has a cultural context, than approval. I think this is particularly true when you consider that sucessful projects have an on-line profile high enough to eclipse the original use of the name. I cannot think of an example where re-using a proper name might have any positive benefit for both parties. I believe that it is right for us to consider ethical questions, and I believe that the solution to this one need not be onerous if podlings are aware of it from the start of their involvement. WDYT:- Should we apply ethical considerations at all? Should we avoid proper names? ... and if not why not? d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
On 17/08/06, Jukka Zitting <[EMAIL PROTECTED]> wrote: I think a key question in the "how" category is how to make IRC (or IM in general) discussions easily accessible to people "who weren't there" ... or who cannot be "there". - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
See my reply to your last post, conversations are OK, but discussions
resulting in proposals can quickly deteriorate into a short circuit
which excludes other participants from the real process, which isn't
about making a boolean decision but about reaching an informed
consensus.
On 15/08/06, Jan Blok <[EMAIL PROTECTED]> wrote:
Hi,
There seems to me a huge difference between doing conversations about
code/design (with a possible conclusion to post a "formal"
change-proposal on the mailing list), and making the decision itself.
Jan
Geir Magnusson Jr wrote:
>Jan Blok wrote:
>
>
>>Hi,
>>
>>What could be the problem of any real-time communication medium usage
>>between some community members as long as every one agrees code and
>>design decisions are made on the mailing list?
>>
>>
>
>Because the reality is that decisions are made on IRC, implicitly. It's
>hard to engage in an argument that already happened, especially when the
>discussion was very conversational rather than formal :
>
>A: what do you think?
>B: Well, like you said before...
>A : about the contstructor
>B : no, the other thing
>A : related to using =?
>B : right that it.. it would be better if that was done as Jim
>suggested
>
>versus the more formal statements people make in email
>
>"I'm beginning to agree that ensuring that re-serializing the Properties
>preserves the original delimiter ("=" in Jim's example) that was used in
>the original file."
>
>geir
>
>
>
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
On 15/08/06, Jan Blok <[EMAIL PROTECTED]> wrote: Hi, What could be the problem of any real-time communication medium usage between some community members as long as every one agrees code and design decisions are made on the mailing list? Because the discussion which results in the proposal is not open to all of the supposed decision makers. A certain amount of out-of-channel chatter is inevitable and probably does oil the wheels, but it can quickly become a problem if a clique forms and starts to steer the dirction of the project without all of the contributors having access to all of the discussion. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
On 15/08/06, Ian Holsman <[EMAIL PROTECTED]> wrote: Obvioulsy we aren't going to agree about this, which is fine, but I'd still like to pick up on a couple of points that you raised; we are talking about stopping people using what they are comfortable with just because we have a few people who don't like it. (who aren't even directly involved in the project). Thats exclusionary to me. With this principle where would you draw the line? Should we then be looking at extending the channels of communication which projects use to include many more forms of communication? What about people who prefer IM or VOIP or web forums or usenet, do you think we should be considering ways in which to include any reasonable and popular means of communication or are your points specifically aimed at IRC? because it isn't. just like a dial-up modem, while perfectly fit for the purpose is no longer used. actually email isn't being used that much locally either... SMS or Skype/IM is what I use most when I want to talk to people. I think you may be extrapolating your personal circumstances too far. No doubt email is becoming less popular, in no small part as a consequence of spam and the fact that the people who should be concentrating on evolving the technology to match our evolving sophistication are focusing a significant part of their attention on spam prevention. On the other hand people do need to communicate across timezones, and in a diverse group any instant communication will exclude people who cannot participate in real time. Many more are prevented from access to instant communication by circumstances, for example corporate firewalls etc. In my circumstances email is very much still the major form of electronic communication in day to day use. > > There is no reason why people can't carry on other forms of > communication, but in order to keep the community alive we should want > to include in the debate everyone who has something to contribute. > we disagree. the community will just grow in a different direction, with other people joining it via IRC sure some people might be disadvantaged by this, but others will be advantaged. I'm not proposing that we compel people not to use other technology, merely that we don't sanction it and we try to encourage people to keep dev and management discussions on dev and pmc lists. Instant communication is great for having private chat with people who you are also having a public discussion with, as long as you don't short circuit the topic. You say that you don't think we should be concerned if people can't participate, and that your circumstances meant that you can miss whole discussions. How would it make you feel if you missed *every* discussion and were only ever presented with high level decisions to ratify after the fact? If people discuss things on IRC and then summarise on a dev list then experience tells us that they will tend to defend the consensus reached elsewhere should anyone should question their decision on the mailing list. Whereas I believe that if the discussion takes place on the mailinglist then everyone is participating as equals and as individuals, and no specific outcome is predicted in advance of the debate. as long as governance can be maintained I don't see why we (the ASF) should care. Well this is logical but you could say the same about any of our activities or policies, why do we defend our licence when we could use any one of many other fine open source licences? Why do we choose to allow people only to contribute as individuals when there is apparently, plenty of corporations who would like explicitly to provide paid contributors? Why have any particular structure or goals? Surely we care because we are commited to the continued sucess of the ASF, and we resist changing the things which demonstrably work because they risk that. I believe that the use of email is one of the essential charateristics of the Apache Way, it has a long history of sucesses and a proven track record here and in other OS projects. Changing the way we communicate will necessarily change the nature of the ASF, the way we operate, and the way we are percieved, and probably change the nature, the amount and the quality of our output. Without evidence (not opinion and speculation) that these changes will be beneficial rather than harmful I think that the risks are too great. We should wish to maintain the factors which have contributed to the success of the ASF, in this case that factor is inclusivity. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
On 15/08/06, Ian Holsman <[EMAIL PROTECTED]> wrote: I don't think we (the ASF) need to support the weakest link of the chain either. if a member can't access a project due to limitations of corporate policy or timezone, we should be OK with that too. not every member has to be able to participate in a project. as long as the project is healthy, I'm not sure what the problem is. Ian this attitude disturbs me, don't make the mistake of thinking that the ASF is big enough to be able to afford to start excluding valuable people and/or groups on the grounds of technology alone. Start making it harder, or more complicated, for people to participate and they *will* leave. I don't see why email, as the lowest common denominator, is not perfectly fit for the purpose. There is no reason why people can't carry on other forms of communication, but in order to keep the community alive we should want to include in the debate everyone who has something to contribute. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
I'd like to add my support to those who, far more eloquently than I could have done, have explained why IRC cannot be an inclusive or truly public forum for discussion. I have always taken the view that email is an essential characteristic of the way the ASF works, and it is precisely because it is globally accessable and asynchronous that real group decisions can be made and real consensus reached. I've always felt uneasy about cliques forming around some out of channel communication, be it phone, pub, ICQ, IRC or, yes, even hackathons. It is not just the decision making which should be public and accessable but the debate that informs the decision making process should be too. In this respect I think that IRC is actually more harmful that the benefit of relationship building which Henri ascribes to it. We are not all capable of participating in other forms of communication and group discussions. However by definition we are all capable of participating in the lists. Relationship building is a Good Thing (just ask my wife!) but it is possible to build personal relationships with other contributors without removing any aspects of the public debate. d. > No it doesn't. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [rant] seperate policy change from proposal discussion
On 08/08/06, Leo Simons <[EMAIL PROTECTED]> wrote: The latest example is all the debate surrounding whether or not the "glasgow" name is appropriate. Up until about a week or two ago, it certainly was accepted practice (just look around), and now 'suddenly' there's messiness. Its ok if opinions change (we had a lng debate a few years ago about "geronimo" as a name and that made it), but it must be very confusing. Perhaps we should have two mailing lists. WDYT? Mea culpa. I made the mistake of provoking a debate on name policy within the Glasgow threads. This, with hindsight, was wrong. I should have started a new thread and used Glasgow as an example instead. I understand that this must have confused and pissed off the Glasgow folks. Please believe that this was never my intention. If I was having a go at anyone it was at the incubator's ASF folks who are much more immune to this kind of random venting in any case. I suppose I expected my voice to be largely ignored, not to whip up a mailstorm. Glasgow folks, please accept my appologies for being a bit ham fisted about the way I did that. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze)
On 04/08/06, Larry Cable <[EMAIL PROTECTED]> wrote: If "Apache" is acceptable for the name of this organization then I see no reason to waste anyone else's time on a rather pointless debate regarding the appropriateness of naming this project 'Glasgow' or not. I don't believe that it is. I certainly wouldn't condone it if it was proposed today. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze)
Robert, Try Apache, and Geronimo. What about Jakarta? I think its time we just stopped this, Glasgow isn't probably too bad. But what if you'd picked Bristol? I'm not picking on you particularly, I just think its time we reconsidered the re-use of proper nouns. d. On 04/08/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: This seems utterly ridiculous to me. "Raises certain moral questions"? "Goes against the wishes of the communities it affects"? Did the residents of Granada feel exploited when Ford decided to name a car after it? How about the Seat Ibiza? Do you boycott Penguin biscuits [a brand of biscuits in the UK] becuse you think it "exploits" penguins? Robert Resident of Glasgow |-+--------> | | "Danny Angus"| | | <[EMAIL PROTECTED]| | | l.com> | | || | | 04/08/2006 14:42 | | | Please respond to| | | general | |-+> >--| | | | To: general@incubator.apache.org | | cc: | | Subject: Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze) | >--| On 30/07/06, Cliff Schmidt <[EMAIL PROTECTED]> wrote: > Does anyone have any further concerns about this proposal? Cliff, yes I do. As you may have seen from previous posts I've only just been catching up with this. My concern is that it is not appropriate for the incubator to continue to condone a practice which at best raises certain moral questions, and at worst can be seen as exploitative and often goes against the wishes of the communities it affects. The fact that Glaswegians may not feel particularly exploited, or that there is a precedent for proper nouns to be used for project names should not matter. What should concern the incubator is, as Robert said, continuous improvement. Please would you at least think about re-considering the name and trying to come up with a proposal which isn't also a proper noun? d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. - 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: Project Naming (was Re: [VOTE] Accept Glasgow into Incubator)
Archit, I'm very happy to here you say so, I certainly don't want to affect your progress through the incubator, in many ways I've unfairly sigled you out as an example of a prectice I feel strongly about. Unfortunately I will be away, offline, for the next four days, but if it is still relevant I will be happy to take up your kind offer and put in time helping to find an acceptable, strike that, a good name. d. On 04/08/06, Archit Shah <[EMAIL PROTECTED]> wrote: The project formerly known as Blaze changed its name to Glasgow based on previous feedback and decided to follow Apache precedent (e.g. Tuscany). Apparently there are strong objections to this precendent. In our discussions, the group did come up with some ingenious names for the project, but most had legal concerns or conflicted with existing software. Glasgow was the winner mostly by process of elimination. Danny, I'm confident that none of the committers are particularly attached to the name and no one wants to see the proposal sidetracked over the name of the project. So, we welcome any help in selecting a name that does not have any software trademarks in the USPTO and isn't connected to other relevant software projects. -- Archit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze)
http://www.glasgowsoftware.co.uk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
On 04/08/06, Gordon Sim <[EMAIL PROTECTED]> wrote: Danny Angus wrote: > I think it is about time that we grew up and introduced a rule which > prevents words already used as proper nouns from being proposed as > project names unless there is some real and relevant on-topic > connection. Just by way of explanation, this name was proposed as (a) it is where the project began and (b) it is a port, which was felt to have a loose association with messaging. As a connection (a) is certainly real, though I can understand that the relevance of (b) might be viewed as rather tenuous. If pressed I wouldn't think that those were good reasons, a) is just a coincidence and b) is a pun. A good reason would be that it had been funded by the city, or had become associated with one if the city's institutions. like the GHC and JAF. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze)
On 30/07/06, Cliff Schmidt <[EMAIL PROTECTED]> wrote: Does anyone have any further concerns about this proposal? Cliff, yes I do. As you may have seen from previous posts I've only just been catching up with this. My concern is that it is not appropriate for the incubator to continue to condone a practice which at best raises certain moral questions, and at worst can be seen as exploitative and often goes against the wishes of the communities it affects. The fact that Glaswegians may not feel particularly exploited, or that there is a precedent for proper nouns to be used for project names should not matter. What should concern the incubator is, as Robert said, continuous improvement. Please would you at least think about re-considering the name and trying to come up with a proposal which isn't also a proper noun? d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze)
On 28/07/06, Martin Cooper <[EMAIL PROTECTED]> wrote: It does seem pretty strange to be naming software after a city, though. Apache Tokyo, anyone? Apache New York? I agree, it is ludicrous. Why is the incubator so fixated on misappropriating proper names? But if you have to pick a Scottish city to name it after, I'd recommend Edinburgh - it's a much nicer city anyway. ;-) Oh great, really mature. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
On 04/08/06, Garrett Rooney <[EMAIL PROTECTED]> wrote: Note that these reasons would have been obvious if the discussion on what to change the name to had happened in public... Quite. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
Hi everybody, I don't have a binding vote here, but.. -1 I strongly object to the name, in some sense I object to this name because it is also the name of the city in which I work, and conversations about "Glasgow" will be a bit wierd. But very much more importantly I would also like to publicly stand up and say that I think it is ridiculous that time after time we misappropriate proper nouns to name our projects with. Stop it. Stop it now. It is misguided to think that it can be done without making a cultural reference, and it is naieve to think that all such references will be appropriate or well received by those whose culture is being misrepresented. The fact that Glasgow is not an impoverished and exploited region of Africa or Asia doesn't make it any less inappropriate to use it as a project name. I think it is about time that we grew up and introduced a rule which prevents words already used as proper nouns from being proposed as project names unless there is some real and relevant on-topic connection. Don't be lazy, if trademarks and IP make it difficult to pick an apropriate name straight away don't just revert to sticking a pin in the map, get out a thesaurus. With the notable and highly significant exceptions of "Apache" and "Jakarta" (both of which raise difficult questions) it seems as if it has only really become common practice since the incubator with Derby, Geronimo, Tuscany, & Woden to name some that I know about. You guys have the chance to stop it by rejecting this project on the basis of its name. Please take this opportunity to stop the rot. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Who is attending ApacheconEU
Thanks to all who stepped up. I'll see you there then. :-) d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Who is attending ApacheconEU
Hi, I'm currently talking to some folks who have an XML based product which allows an XML schema marked up with additional attributes to generate a whole b2b web application. You can see some details here: http://164.36.45.6/fox/ They're keen to move this into open-source and I was wondering if any apache-ites would be available at apacheconEU for me to talk to about it and possibly to introduce these guys to. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: donation of project
Hi Matt, > My company is interested in donating a project to the Apache >Foundation. Specifically, we have created an updated HTML editor kit A swing Editor Kit? Cool. 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: [VOTE] Official Name for "Geronimo" Project
> Geronimo was an Apache was he not? So it definitley seems odd that we > can name our whole organization after the people of Geronimo but not > Geronimo himself (yes, I know the name came from "a patchy server, but > that's not obvious to anyone most of the time). I understand that Andy Oliver contacted a (or more?) organisations representing Native Americans. I've lost the messages but AFAIK the response was cautiously un-enthusiastic, and the respondant considered that other groups may be more hostile to the idea. 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: incubator, exit and publication
Stephhen, "At the end of the day we need to address the issue of wht rights the Incubator PMC has to endorce the publication of an artifact generated by a project prior to the exit of said project from the incubator. Publication by a Sponoring Entiry is a different subject - but publication by the Incubator is a loaded question." Surely the incubator has the right a-priori. The incubator PMC is charged with responsibility for releases, and the podling has accepted to be bound by the PMC. As long as the release itself is legal the PMC has the right to exert its judgement. Only if the release would legally compromise the ASF would the Incubator PMC be bound to veto the release, whether or not any formal process has been followed to ensure legality. The PMC isn't bound to enforce a process leading to legality, but to enforce the legality itself. If we assume the PMC actually do take an interest in the podling and will make the effort to ensure that code is correctly licenced etc. then why on earth would they not have the right to sanction a release on their own authority? This is not a democracy. The code is Open Source but that doesn't mean that the processes have to be, the ASF is a corporation after all, and tries to run as a meritocracy, surely one key feature of a meritocracy and a sucessful corporation is that you give responsibility to people who have proved themselves, you *trust* them to make an honest job of things, and you sack them if they don't deliver (or sue their little asses)? 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: incubator, exit and publication
Stephen, While you say "Ok - going with Apache tradition - its not the PMC that makes the decision of a *release*. Its the committers in the incubator (who basically represent a bunch of rather non-incubator interest groups). " In fact while that represents the Jakarta tradition I think it is one of the things that the re-organisation and the incubator were intended to end. PMC's are now expected, by the board as expressed by Greig, to be formed of as many commiters as would like to be included. And PMC's have a duty to be the final arbiter of releases. Hence one effect of promotion of James, Avalon, Ant etc is to normalise the situation whereby those projects had de-facto autonomy in this respect. The same folks are making the same decisions, but are now officially mandated to do so. The next symptom is the changes to the Jakarta PMC which have seen it become inclusive, unlimited in size and recently seriously attempting to ensure that every sub-project is _properly_ represented, precisely so that the PMC can make informed decisions on releases and so on, rather than rubber stamping the decisions of commiters (to be fair it seems to me that this is a problem caused by Jakarta's sucess, whereby the project grew too large for enough trust to exist for this responsibility to be delegated, and for a small PMC to have real oversight of every corner of each sub-project). Thirdly the incubator PMC is now (I think?) officially mandated to do this for the incubator. In the context of this discussion I'd assume that it is even more important for the decision to be a considered one in the incubator because of the points raised already about commiters being possibly less indoctrinated in The Apache Way. (help I can't make Notes prefix replys with ">" ;-) You also say: "Perhaps you can explain to me how the action of the Incuator PMC with respect to publication of an artifact and its reciprical impications towards the liability of the ASF is something that can be held up with *integrity* while at the same time, the Incubator PMC has not facilitated the exit of said podling. If a podling has not exited - then it clearly has not met Incuabtor exit criteria - then equally clearly, the Board has not established due-diligence, therfore - on what grounds can a release be published?" Surely the incubator PMC is primarily responsible, in the context of a release, only for ensuring the legality and desirability of the release? I don't see linkage between this and exit, if a podling has not met exit criteria owing to factors such as process and community the contributors may still be able to make a case for releasing an artifact, it then surely falls to the incubator PMC to decide based on things like IP ownership and other legal matters. If the podling is incapable of preparing the release acceptably then the incubator has more work to do, if not then it doesn't follow that the podling is ready for exit, there may be unrelated issues to resolve. You also imply that the incubator PMC have the opportunity to unreasonably resist or obstruct exit yet still permit releases, were this to occur it would be serious, but we do have to rely primarily on the judgement of the PMC, thats the whole point of the incubator. Where we believe this judgement has failed surely our (non PMC "interested bloke") course of action is clear? We fall back on precedence, notifying higher authority (the board), proposals, votes, and heated debate, collectively known as The Apache Way. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** 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. ** --
Re: Sub-project -> TLP
Craig wrote: >Off the top of my head ... advantages include: IMO you missed out "Your own PMC and charter" These two things represent a quantum difference in the management of a TLP c.f a jakarta sub-project, as the bring with them the ability (within the restrictions of "The Apache Way" and your charter) to define the scope and activity of the project, its goals and procedures. You also say: "Overall, I suspect the lack of a stampede towards TLP-hood has more to do with lack of knowledge of the advantages, or indifference towards them, and possibly fear that even mature subprojects that want to graduate will have to undergo the incubation process :-), than it does anything else." My experience with James was that we felt generally uncomfortable under Jakarta, no grudges or anything like that but it seemed as if James no longer fitted well with the de-facto web orientation of Jakarta. Even admiting this it was still a leap into the unknown and bit of guesswork and faith to become our own TLP. I think Jakarta PMC or Incubator people could do a lot to encourage Jakarta sub-projects by simply publishing a bulleted list of the steps you have to take (yes I know, I should do it myself) and the responsibilities you have after elevation. So that anyone who wants to consider their future can find this out without having to declare an interest on a mailing list. The public nature of lists and the endless mis-interpretation of motives and personalities that goes on here often make it difficult to discuss the general case without having people infer the specific. It might also benefit people to hear of our (James') experience: We had a mature sub-project, with an easily defined scope, a small commiter base and a need to change, we wanted to have the ability to extend the project and possibly to host sub-projects, and we wanted James to be presented and concieved as complete and mature product. We adopted our procedures initially from Jakarta and have only changed them (by refrence not by value!) as far the trend towards ASF wide definitions of common procedures has allowed. The infrastructure changes weren't onerus, and the PMC mailing list now has nearly zero traffic. Interest in our project has being building, from a pretty stable level, steadily ever since. We're now attracting the attention of people who are first and foremost specifically interested in what we are producing and not, as before, only those who had managed to find James lurking in Jakarta. Several people have described James as a well kept secret, TLP status for James means that we can address this and "build brand awareness" amongst contributors, users and the ASF alike. 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]
contributors licence
Hi, Is there a contributors licence which can be signed by an employer on behalf of a commiter who's IP is generally assigned to their employer? I have an agreement with my employer, but would much rather that they made the agreement with the ASF *** 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] Creating graveyard.apache.org
> What about "morgue". The things may be dead, but the living still want to poke them about a bit before they are finally buried.. or perhaps brought back to life again in the "return-of-the-living-dead.apache.org" project. ;-) d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why solve a problem that doesn't exist?
Jochen, you wrote: > Quoting Greg Wilkins <[EMAIL PROTECTED]>: > > > However, open process is at least as important as open software. > > Agreed. But the ASF has just given a bad example on this (IMO). > Following the discussions on Geronimo in the last days, my > impression is that a lot of decisions (in particular architecture) > has already made behind the scenes. I do not even know who took > those decisions, or how they look like. I think that this is a very unfair comment, and would like to take some time to explain why I believe this. Apache doesn't have a simple way to start a project from scratch, but does have mechanisms for accepting existing projects. I expect that it is simpler and more productive for the sponsoring individuals and the Apache process to start the project first, and then have it accepted into the Apache incubator. There is little reason why any aspect of a project cannot be changed retrospectively should the community reach agreement, those reasons are pretty much limited to conforming with the project's charter, the legal obligations of the ASF, practical constraints imposed by infrastructure, the rules governing contributors roles[1], and whatever additional rules are imposed by the project itself. In this case the governing project is the incubator, but if or when geronimo becomes a fully fledged Apache project those rules themselves are open to modification by the community through its project management commitee. Once geronimo has become an Apache incubator sub-project it will be governed by Apache's rules and processes, therefore no condition that pre-exists the creation of the project is treated any differently from any condition arising afterwards, if you don't like decisions that have been made when the project was a private one you will be at liberty to comment on them and lobby for change, or if you are elected as a commiter you will be able to make proposals and cast binding votes. For example the rules governing Jakarta and inherited by Jakarta sub-projects are documented here http://jakarta.apache.org/site/guidelines.html other project have similar processes[2], it is this, and other interpretations of "The Apache Way" that characterises the management of Apache projects. One final point I'd make is that Apache doesn't pretend to have entirely open management, Apache has to exist in the real world of lawyers and corporations, but it does exist to foster collaborative and consensus based process. This commitment can be best illustrated by refering you to the very first paragraph of the ASF website[3]. "The Apache Software Foundation provides support for the Apache community of open-source software projects. The Apache projects are characterized by a collaborative, consensus based development process, an open and pragmatic software license, and a desire to create high quality software that leads the way in its field. We consider ourselves not simply a group of projects sharing a server, but rather a community of developers and users." I've been part of this community for a bit more than a couple of years now, and I can assure you that I've never experienced any decisions which have been sucessfully imposed without either consensus or a majority vote of the appropriate constituency, and remember this is a meritocracy, to join the constituency and help make the decsions you care about all you really have to do is to demonstrate your willingness and ability to participate at the appropriate level. d. [1] http://www.apache.org/foundation/roles.html [2] http://nagoya.apache.org/wiki/apachewiki.cgi?PoliciesAndProcedures [2] http://www.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Marc Fleury reacts (Fw: [JBoss-dev] July 2003 news)
> More on how close Sun/ASF are: > http://www.mail-archive.com/[EMAIL PROTECTED]/msg07802.html I think ASF and Sun voting the same way when the choice is Yes or No, is pretty poor evidenc of a conspiracy. What would you be saying if ASF and IBM had voted No, found a conspiracy where IBM and ASF were ganing up on Sun? Get real. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [geronimo] Me, James and javaMail
> What I would like to see for a > future release of > Geronimo is an E-Mail Message Bean container. That is, a Message > Bean that can > process incoming e-mails. We already have the Mailet API see: http://james.apache.org I'd be more interested in adapting this, and implementing a mailet container for geronimo than creating anything new in this space. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Marc Fleury reacts (Fw: [JBoss-dev] July 2003 news)
> Sun is on the ASF board I think? Apparently not: Current officers of The Apache Software Foundation: Chairman Greg Stein President Dirk-Willem van Gulik Treasurer Chuck Murcko Exec. V.P. and Secretary Jim Jagielski V.P., Apache Ant Conor MacNeill V.P., Apache Avalon Berin Loritsch V.P., Apache Cocoon Steven Noels V.P., Apache Commons Ken Coar V.P., Apache Conference Planning Ken Coar V.P., Apache DB Jason van Zyl V.P., Apache HTTP Server Sander Striker V.P., Apache Incubator Jim Jagielski V.P., Apache JAMES Serge Knystautas V.P., Apache PHP Rasmus Lerdorf V.P., Apache TCL David N. Welton V.P., Apache Web Services Davanum Srinivas V.P., Apache XML Berin Lautenbach V.P., APR Cliff Woolley V.P., Jakarta Sam Ruby V.P., Java Community Process Geir Magnusson Jr. V.P., Perl-Apache Doug MacEachern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why solve a problem that doesn't exist?
> Why must people's egos get in the way of common sense in our business as > in so many? Like Microsoft, it appears that Apache.org just wants to > control everything - and that's just such a lamentable motivation, > whether held by Microsoft or Apache.org. Actually it appears to me that Apache is attempting to provide an alternative and/or complimentary product to JBoss. This potential increase in consumer choice seems to me to be diametrically opposed to the Microsoft tactics you allude to. As far as I can ascertain there is no ill will being directed at JBoss or any other organisation, Open Source or commercial, by this move. Rather it would seem that what negativity is around is being directed at this project before it has even got off the ground, released a single design document, a charter, or any code whatsoever. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [geronimo] Me, James and javaMail
We are still open for considering proposals to be included in Mailet v3. I suggest that if there are appropriate changes which could be made to the API to make it conform with anything relevant you subscribe to [EMAIL PROTECTED] and put forward some proposals with reasoning. Please be aware that we're pretty happy with the API at the moment, it has been stable for a long time and serves it purpose well, so we're probably not too recepetive to radical overhaul, but are receptive to sensitive extensions where they may lever it into new territory (like this). d. > -Original Message- > From: Richard Monson-Haefel [mailto:[EMAIL PROTECTED] > Sent: 07 August 2003 10:16 > To: Danny Angus > Cc: [EMAIL PROTECTED] > Subject: Re: [geronimo] Me, James and javaMail > > > I just took a quick look at James. Nice job. I think the Mailet API is an > excellent component model and would work well as an MDB. We would need to > write adapters to make the Mailets conformant with EJB 2.1, but I don't > think that will be very difficult. What we will need to do, however, is > wrapper the calls to the Mailet with transaction and security control that > is consistent with the EJB 2.1 specification. Again, I don't think this > will be a big problem. Anyway, it looks good to me. I'll be happy to help > integrate James with Geronimo. > > Danny Angus wrote: > > > > What I would like to see for a > > > future release of > > > Geronimo is an E-Mail Message Bean container. That is, a Message > > > Bean that can > > > process incoming e-mails. > > > > We already have the Mailet API see: http://james.apache.org I'd be more > > interested in adapting this, and implementing a mailet container for > > geronimo than creating anything new in this space. > > > > d. > > -- > Richard Monson-Haefel > Author of J2EE Web Services (Addison-Wesley 2003) > Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001) > Co-Author of Java Message Service (O'Reilly 2000) > http://www.Monson-Haefel.com > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Names & Projects
> Isn't Geronimo something you yell when you jump out of a > plane? By which token Banzai! would also be politically incorrect.. ;-) d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: the name, Geronimo
I'd like to propose KARAKATOA as an alternative name, for those who don't know it's a volcano, in Indonesia. If that's taken, which I suspect it may be, then how about something with no clever relationship to anything at all, like TwentyOne, or Charm, or Furnace d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[geronimo] Me, James and javaMail
Hi, Probably biting off more than I can chew here, I'm currently as busy as the day is long :-(, but I'd be happy to look at implementing javaMail for Geronimo. For those who don't know who the hell I am (or what I'm taking about) I'm a James developer, and James is Apache's 100% Java mailserver. Its worth noting that the James developers have, from time to time, had "issues" with the design of Java mail, primarily that it is a client oriented API which makes life difficult for server developers, we're left with the choice of rolling our own or shoehorning round pegs into square holes. Notwithstanding this there are already moves afoot to create several alternative implementations of javaMail abstract classes, (particularly message "Store"s[1] where we see a market for implementations of MBOX and other popular text based systems), and we've also toyed with the idea of providing our own outgoing SMTP implementation (we currently use javaMail) in order to have greater control over outgoing mail behaviour (we'd like to optimse sending and implement connection re-use), and given that we're here discussing Geronimo perhaps this could be an implementation of "Transport"[2] to replace com.sun.mail.smtp.SMTPTransport >From the POV of creating another javaMail implementation you may not realise that Sun have already put a huge amount of implementation into javax.mail.*, and very much of the inheritance root of javax.mail classes is made up of abstract classes rather than interfaces. You only have to look at the javadocs for j2ee to see that there's a much greater ratio of classes (abstract and concrete) to interfaces in javax.mail than most other packages. Unfortunately this removes much of the scope we would like to have for "correcting" the client bias in the API, by creating a ground-up server-centric implementation. Anyway I guess I should wait 'till we get a geronimo list before discussing this much further. d. [1] http://java.sun.com/j2ee/1.4/docs/api/javax/mail/Store.html [2] http://java.sun.com/j2ee/1.4/docs/api/javax/mail/Transport.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
