Re: On unity and coherence [was Re: [Request For Comment] POI@apache]

[Andrew C. Oliver]

MY APPOLOGIES.  I realize some of these have already been covered and
that this is "out of step" with time.  I got some messages back because 
roadrunner (my ISP) seems to be using a Windows SMTP server.  (deduction
I make from the outages corresponding with the latest windows
code-red-and-friends):



> > >> I am not trying to be combative - I have watched this thread (and
>> participated) with growing discomfort.  I have to say that I think
that
>> bringing XML and Jakarta together might destroy the thing we are
>> supposedly
>> trying to 'save' (again, I don't get the problem...), namely the
>> community
>> that each group has.  Larger isn't always better.
> > I kinda agree with you on that.

> Ted didn't write that.  I did.

I realize that.  It was a cut and paste error.  I have to quote manually
because I get the digest form of this list.  



> > Maybe its not yet time for a vote.  Let me state this again and make
it
> very clear.  POI has many users and many uses.  No one I know of is
> using POI on the client.

>Maybe you have some marketing problems? :)

I doubt it.  We're #4 on sourceforge :-p.  

Though you might be right.  A developer on the POI project called me
John Lennon today and implied I might be shot.  ;-p

> POI is as client-side as Tomcat is.

>Why do you say that?  It is used on the server side, and that's
>fantastic,
>but in my opinion (note that I recognize I am  a complete outsider to
>your
>project who would be defined as a user) it seems client side.

No you'd not be defined as a user.  You've not used POI ;-)

>If I had a need for something like this (and I bet I will at some
>point),
>and I had the choice to look at either>
>
>  a)  jakarta, the apache java server-side focused project or
> 
>  b)  floccinoccinihilipilificator*, the apache java client-side
>project


>I would choose b), as I think of word and excel as a client-side
>thingy.  No
>matter that my use is server-side...

So what about the stuff to write PDF Files?  What about Batik?  (renders
graphic files).  You have a very unique point of view on what is "server
side" and what is client side.  I'm afraid we'll have to disagree
philosophically on that.  Basically if in my opinion if it runs ON THE
SERVER and is practically never used ON THE CLIENT, its server-side.  


>> (Tomcat is
>> used by Netbeans a pure Java-IDE on the client!).  HTML is for use on
>> the client right?

>Yep.  But its a markup definition, not an API implementation.

And Avalon is a framework (which could be used clientside).  Log4J is
used by HSSF currently.  


>> So is a library that outputs in HTML is clientside or
>> serverside? 

>Serverside generally, as the canonical model of HTML use is the web,
>with a
>clear delineation of server and client.  However, it indeed has
>clientside
>uses - take for example any help system that outputs HTML within a
>monolithic desktop application.

This is reaching philosophical levels.  Log4J is an API for logging as
is LogKit.  Both are just as useful in both places.  (And :-o POI uses
Log4J...  If we use geometric theorems here then that makes Log4J
clientside too ;-) ).

>Conversely, I would argue that Excel is a totally client-side
>technology,
>and therefore a library that works with XLS files is clientside
>generally as
>the canonical model of Excel is on the desktop.  However, it indeed has
>serverside uses

The browser is on the desktop too.  I can see we're not really going to
come to agreement on what is server and client side.  ( I avoid such
philosophical discussions...they have no logical conclusion ).

> Cocoon publishes documents that are generally read on the
> client right? 

>Yes, but it's more than an API, right?  (I don't know much about
>cocoon...)

It has a Servlet or you can run Cocoon from the command line as well.
Cocoon is an XML publishing framework.  

>>From what I read, POI is an API that accesses data in XLS files... 
>Theres a
>huge difference.

NO.  Please take another look.  We do full READ AND WRITE libraries or
its not worth my time. Document generation and reading.  (I wouldn't
bother to bring an API for reading into the world, too many ways to fry
that fish already)

POI is a project providing complete ports of OLE2 Compound Document
based file formats

POIFS is a pure java port of OLE2 CDF - READ AND WRITE

HSSF is a pure java port of Excel file format - READ AND WRITE

HSSF Serializer is a Cocoon 2 serializer using HSSF - it serializes XML
spreadsheets as XLS (Excel not XSL :-p).  It shares the same XML tag
library as gnumeric.

The HSSF Generator will be written soon.  (refactoring.  My $ says this
time next week we have the HSSF Generator proof of concept nailed out)
The HDF library is going to kick off shortly.  It will be a full port of
DOC format.

>And Cocoon isn't part of Jakarta, is it? :)

No.  That wasn't the point.  It was server versus client-side.

>I don't necessarily think that xml.apache.org is the right place
>either,
>although I am not a mem

Re: On unity and coherence [was Re: [Request For Comment] POI@apache]

[Andrew C. Oliver]

MY APPOLOGIES.  I realize some of these have already been covered and
that this is "out of step" with time.  I got some messages back because 
roadrunner (my ISP) seems to be using a Windows SMTP server.  (deduction
I make from the outages corresponding with the latest windows
code-red-and-friends):


>Playing Devil's advocate.  I think it's fair to push back on adding
>things
>to Jakarta...

Fair enough.  

On 1/5/02 9:53 PM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:
> > Please read these posts and then tell me where you're not clear?
> >
http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html

>Isn't it fair to guess that the majority of your server side use would
>be
>reading documents for presentation, indexing, searching?  However, you

No.  you're forgetting about reporting and publishing.  Some crazy
people also use HSSF to do XLS database dumps.  (I said they do it, not
that I think its a good idea)

 >point
>out in the above link that the thing that makes POI special is it's
>ability
>to *write*?  What's the % of mainly writing to mainly reading on the
>serverside?

Thats a good question, I have no solid figures.   

By my estimates it fluctuates greatly.  I'd say we'll see a trend that
will eventually level off to 50/50.  If you'd have asked in December I'd
have said more read.  This week it seems everyone is very focused on
generation.

> http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html

>Paulo might use VB to make a client side app, but I wouldn't if I
>wanted
>portability, especially if I was looking to the handheld or embedded
>application that could access a document remotely...

most people see embedded as a whole 'nother beast.  You'd also not use
POI for embedded.  You know why?  M$ uses completely different file
formats for the embedded versions.  

Anyhow the argument is not that POI could NEVER be used on the client
side, its that its far less useful on the client side. 

If I were coding to Excel on the client I'd write a macro.  VBA would
work (I suppose...I dunno I have a palm v) and both the client and the
pocket pc.  Okay... I wouldn't code to Excel on the client because
itsyucky.  

> http://www.mail-archive.com/general%40jakarta.apache.org/msg02690.html

>No comment, as it's an agreeable followup to the above.

Sorry, maybe that was the wrong message.


-Andy

-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: On unity and coherence [was Re: [Request For Comment] POI @ apache]

[Paulo Gaspar]

As a newbie (only 1.5 years around) I found the small bio posted by
Stefano on the Cocoon-dev list very interesting and instructive.

This post was triggered by curiosity and know-your-community concerns
that popped up in a couple of Cocoon-dev threads less than 2 months
ago. IMO, the fact that it is written in the first person only helps.

To ease the task of searching for it, I am just attaching it. Maybe
Ted and others can use it as an historic source.


Have fun,
Paulo Gaspar


> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 06, 2002 3:48 PM
>
>
> Ted Husted wrote:
>
> > At this point, I'm reconciled to do more work on the Jakata site using
> > XML in the old-fashioned way.
>
> I can't resonate more with your feelings. That's exactly what made me
> started the 'forrest' effort: the coherence on xml.apache.org and the
> ease of update has been slowly falling apart until now when people can't
> even run in on their machines without getting fonts problems (yeah,
> blocked by fonts problems! go figure!)
>
> > We have some unratified guidelines that expand on the ones (you?)
> > originally set down.
>
> No, that wasn't me to edit that page, even if much was taken from my
> java.apache constitution (as you indicate below), which on my side, took
> from the old dev.apache.org guidelines for [EMAIL PROTECTED]
>
> > http://jakarta.apache.org/site/proposal.html
> >
> > If you were able to review them, I would of course very much like to
> > have your comments before making a final update and calling for a vote.
>
> I'm honored. I'll do it ASAP.
>
> > I would also like to add more rationale for some of the guidelines. The
> > recent dicussion regarding coding conventions had less to do with the
> > conventions themselves, and more to do with why we even have
> > conventions. (And having conventions, why don't we enforce them.)
>
> Good point.
>
> > As Jakarta grows, it becomes more and more important that we have better
> > ways to introduce peoole into the fold. Right now, there is a tendency
> > to make someone a Committer and let them find their own way around. At
> > this time, I'd like to go to work on a Committer's guidebook that would
> > help explain how things are done (starting with How to do a Release --
> > which raised the JAR discussion the other day).
>
> Oh, gosh, you are probably unaware of the fact that I'm the one that
> continously pisses people off on the ASF member list (unfortunately
> private) about having those 'committer guidelines' up and running. James
> Davidson and I were the one who made the page on how to setup your SSH
> tunnel for CVS.
>
> Yes, this is the right direction, but people must commit to keep those
> guidelines up 2 date and many people (expecially apache root's) failed
> miserably to do it.
>
> Also we must make those easy to find.
>
> Again, Forrest will help.
>
> > I think the real solution to improving the noise:signal ratio is to move
> > away from the "oral (email)" tradition we have now, and move back toward
> > providing more grassroots documentation, as you did in the "preamble" to
> > the original constition.
> >
> > http://java.apache.org/main/constitution.html
>
> Absolutely.
>
> > An actual history of Jakarta might also be useful to give people a
> > better perspective. Here's one passages I tucked away (to be joined by
> > your own snippets of late).
> >
> > Pier to Jon - Thu, 21 Dec 2000
> > > We've traveled a long
> > > way together, from my very first steps in open-source land in
> January 1998,
> > > to our marvelous meeting at the first ApacheCON in October
> 1998, the Jakarta
> > > room meeting, all JavaONEs, and all we did together to bring
> this project
> > > where it is right now.
> >
> > Pier again, same day
> > > And we, as the newly formed Apache Software Foundation,
> accepted that code
> > > in donation as a point of start for the Jakarta Project. I
> was there, in
> > > that meeting room, that day when we outlined how the process
> would have
> > > evolved, with Jon, Stefano and Brian. And I was there, on
> stage at JavaONE,
> > > when Patricia Sueltz announced the spinoff of the project
> againg with Jon,
> > > Stefano and Brian. If that has been a wrong decision, we four
> are the people
> > > to blame...
> >
> > A coherent history might help with many of the questions about why we do
> > things the way we do. (Or why we don't do some things at all.) I think
> > clearly documenting the Apache Way would be an important first step to
> > unifying the Apache Projects.
>
> Great point. I absolutely agree.
>
> > I would also like to personally commend Jon with his efforts to better
> > document Jakarta. He has put a lot into the Web site (probably 90%), and
> > we all owe him a great debt.
>
> Oh, I never even thought about questioning this.
>
> I personally owe everything to Jon: without his kind messages, I
> wouldn't have remained around the community enough to get the 'apache
> fe

Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]

[Stefano Mazzocchi]

Ted Husted wrote:

> At this point, I'm reconciled to do more work on the Jakata site using
> XML in the old-fashioned way.

I can't resonate more with your feelings. That's exactly what made me
started the 'forrest' effort: the coherence on xml.apache.org and the
ease of update has been slowly falling apart until now when people can't
even run in on their machines without getting fonts problems (yeah,
blocked by fonts problems! go figure!)
 
> We have some unratified guidelines that expand on the ones (you?)
> originally set down.

No, that wasn't me to edit that page, even if much was taken from my
java.apache constitution (as you indicate below), which on my side, took
from the old dev.apache.org guidelines for [EMAIL PROTECTED]

> http://jakarta.apache.org/site/proposal.html
> 
> If you were able to review them, I would of course very much like to
> have your comments before making a final update and calling for a vote.

I'm honored. I'll do it ASAP.
 
> I would also like to add more rationale for some of the guidelines. The
> recent dicussion regarding coding conventions had less to do with the
> conventions themselves, and more to do with why we even have
> conventions. (And having conventions, why don't we enforce them.)

Good point.
 
> As Jakarta grows, it becomes more and more important that we have better
> ways to introduce peoole into the fold. Right now, there is a tendency
> to make someone a Committer and let them find their own way around. At
> this time, I'd like to go to work on a Committer's guidebook that would
> help explain how things are done (starting with How to do a Release --
> which raised the JAR discussion the other day).

Oh, gosh, you are probably unaware of the fact that I'm the one that
continously pisses people off on the ASF member list (unfortunately
private) about having those 'committer guidelines' up and running. James
Davidson and I were the one who made the page on how to setup your SSH
tunnel for CVS.

Yes, this is the right direction, but people must commit to keep those
guidelines up 2 date and many people (expecially apache root's) failed
miserably to do it.

Also we must make those easy to find.

Again, Forrest will help.
 
> I think the real solution to improving the noise:signal ratio is to move
> away from the "oral (email)" tradition we have now, and move back toward
> providing more grassroots documentation, as you did in the "preamble" to
> the original constition.
> 
> http://java.apache.org/main/constitution.html

Absolutely.
 
> An actual history of Jakarta might also be useful to give people a
> better perspective. Here's one passages I tucked away (to be joined by
> your own snippets of late).
> 
> Pier to Jon - Thu, 21 Dec 2000
> > We've traveled a long
> > way together, from my very first steps in open-source land in January 1998,
> > to our marvelous meeting at the first ApacheCON in October 1998, the Jakarta
> > room meeting, all JavaONEs, and all we did together to bring this project
> > where it is right now.
> 
> Pier again, same day
> > And we, as the newly formed Apache Software Foundation, accepted that code
> > in donation as a point of start for the Jakarta Project. I was there, in
> > that meeting room, that day when we outlined how the process would have
> > evolved, with Jon, Stefano and Brian. And I was there, on stage at JavaONE,
> > when Patricia Sueltz announced the spinoff of the project againg with Jon,
> > Stefano and Brian. If that has been a wrong decision, we four are the people
> > to blame...
> 
> A coherent history might help with many of the questions about why we do
> things the way we do. (Or why we don't do some things at all.) I think
> clearly documenting the Apache Way would be an important first step to
> unifying the Apache Projects.

Great point. I absolutely agree.
 
> I would also like to personally commend Jon with his efforts to better
> document Jakarta. He has put a lot into the Web site (probably 90%), and
> we all owe him a great debt.

Oh, I never even thought about questioning this.

I personally owe everything to Jon: without his kind messages, I
wouldn't have remained around the community enough to get the 'apache
feeling' out of it.

Jon and I have very different technical views and very different ways of
doing software architectures and sometimes some friction develops, but
all the times I land in SFO, he's the first one who I call to hang out
with! :)

[yeah, people, the 'rude' Jon Stevens was the one who gave Pier and I
hospitality in his place when we came to ApacheCON 98 and we didn't have
a place to stay since we had to pay our own expenses]

Gosh, Ted, you're right, we should write this history down someplace and
let people know how we came here.

-- 
Stefano Mazzocchi  One must still have chaos in oneself to be
  able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
-

RE: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Paulo Gaspar]

> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 06, 2002 6:55 PM
>
>
> On 1/6/02 12:58 PM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:
>
> ...
>
> If you start at the top of the thread, I declare I am playing devils'
> advocate, and addressing the three URLs that andrew gave.

The Devil's advocate gets flamed as any other one or more, didn't you
know?
=;o)

> I don't think it "should" be used for anything - that's up to the
> users and I would never try to make an assertion to that end.

YYYs!!!


> To give you the benefit of the doubt that I wasn't clear, change
> "would be" to "currently is" as that is what I meant.
>
> The dissonance that struck me was between the thing that makes
> POI different
> - the ability to write xls files - and what I read to be the most
> common use
> - reading xls for serverside presentation and indexing.
>
> I'm just trying to figure this out.

I also got surprised by that one but is was exactly what made me
realize how much "server side" (here we go again) it was.

It looks like our POVs on this are being heavily influenced by our
current work experience and needs... which are different.


> ...
>
> The fact that Velocity can generate HTML doesn't make it special.

Yes, it is the HOW that is quite especial!
=:o)


 ...

 Are there many uses for writing Word/Excel documents in a client-side
 device that has not Word or Excel installed???
>>>
>>> You might find this unbelieveable, but not everyone works on a
>>> computer that runs an operating system that has Word or Excel available.
>>
>> And is there many people NOT having Word or Excel installed that care
about
>> writing Word and Excel documents in a CLIENT device???
>
> YES.  Anyone who uses Linux is an example. (sorry, I've found open-office
> and gnumeric don't really cut it...)

But POI is no replacement for that.

You just add to the argument that there is not much use for writing a
Word/Excel document in a client device without Word/Excel... in the way
that POI does.

The use for POI is to write the doc in a server to send the document to a
client that has Word/Excel or some future version of OpenOffice.
=;o)


This is not about POI being "server side" or "client side" in terms of
being acceptable for Jakarta. I think that we already cleared that side
(its too subjective and up to the users.)

This is just about POI usefulness.


> However, of course that I want to write such formats on a SERVER device
> without any MS stuff (Linux), so that clients WITH MS software installed
> can read them.
>
> ...

Have fun,
Paulo Gaspar


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: On unity and coherence [was Re: [Request For Comment] POI@apache]

[Sam Ruby]

Andrew C. Oliver wrote:
>
>> I doubt you are that different.
>
> *Looks down at his cookie monster slippers*

+1!

- Sam Ruby


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI@apache]

[Geir Magnusson Jr.]

On 1/6/02 1:17 PM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:

> The avalanche has already started. It is too late for the pebbles to
> vote.
> -Ambassador Kosh

One of my favorite lines...

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"Now what do we do?"


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: On unity and coherence [was Re: [Request For Comment]POI@apache]

[Andrew C. Oliver]

>Answer inline

>> -Original Message-
>> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
>> Sent: Sunday, January 06, 2002 3:53 AM
>> > > ...
>> >
>> >I can not express this POV better than Linus did in posts reported
by 
>> >this article:
>> > http://kerneltrap.org/article.php?sid=398
>> >
>> >Any corporation "organizizes" things and I do not see better user 
>> >understanding there.
>> > My viewpoint is a bit different then Linus on some things.  

>Keep in mind that Linus does not favor complete anarchy, as is obvious
>from the grip he has on Linux.

Yes.  Linus has different beliefs in release management.  I'm a bit more
disciplined in style.  Don't get me wrong, Linus is like my idol and
all, just I bet I'm far more likely to do a sequence diagram or write
documentation.  We have different viewpoints on a lot of different
things.  Yet I don't care to maintain as tight of control over POI.  I'd
exert my say if say someone wanted to do the equivalent of maybe embed X
inside the kernel (like the whole thing) directly, but mostly I don't
try to direct things quite as much in some areas.  

>>The point is that too many restrictions are bad. The problem is to 
>>find out what "too many" is.

>IMO, things can be improved but the main problem is not lack of rigid 
>discipline. 

true, I wasn't meaning to say rigid discipline would.

>As an example of "too many" or "too less" restrictions, I believe that:
> - forcing every project to follow the same code conventions would be
>   counterproductive;

Completely and TOTALLY agree.

> - forcing each project to have explicit code conventions and follow 
>   them would be just fine.

As long as those projects can have explicitly lax coding conventions in
places where others would be more rigid.  (POI - write good code.  be
self consistent and we all kinda agree that embedded ternary operators
is the most evil sin of all)

>It is good to have diversity. There is the cross pollination effect and
>there is also the fact that what one group things is better is not so 
>sure that it should be imposed.

+1
 
>> >Besides, there is no such thing as an Open Source external customer.
>> >Those that contribute to it (the authors and even noisy guys like
me)
>> >ARE the customers.
>> > >People PAY Open Source by participating. If something is wrong FIX
IT!
>> > I don't completely agree with you on that.  Some contributions to
Open
>> Source are less quantifiable than others.  I see I'm a bit
>> morecommunistic.  I'm so far the the left on this that I'm on the
>> right?  

>I doubt you are that different.

*Looks down at his cookie monster slippers*

> is not withing to POI's mission, that won't fly.  (There will be NO
GUI
> components in POI)... If they feel like working on a feature that I
just
> don't think is in our critical path...go at it.  

>So, you try to keep people happy but you are not so communistic that
you
>make everybody happy (which would be crazy, I agree).

Which reminds me of an Abe Lincoln quite.
 
>> Anyhow I contributed ideas.  Take them for what they were.  They were
>> NOT complaints.  Apache is the most healthy opensource group there
is.
>> > (its healthier then GNU IMHO)

>I also believe so, of course.


 
> >You probably know what I am talking about since POI is Open Source.
> > POI is opensource, there are some differences of opinion between you
and
> I on who the "contributers" are.  To me:
> > User: doesn't submit patches, but uses the software.  The more
people
> who USE POI the better and healthier POI is.
> > For example.  A user the other day sent a bug.  He had an toasted
XLS
> file.  It had confidential data in it so he couldn't contribute a
> sample.  I talked him through running HSSF through a debugger and he
> found the problem.  HSSF 1.0.1 can't handle cells with strings over  
> 15,000 characters long if they don't occur early in the file.  (there
> is a static string table and it is kinda blocked or paged).

> You are talking about users that contribute something to the projects:
>they test it, report problems and help making it more solid that way.

> I still do not see any difference in your opinion.

Gotcha.  It often does not seem that many agree with this viewpoint.

>In my posting I even including this paragraph:
>  Besides, there is no such thing as an Open Source external customer. 
>  Those that contribute to it (the authors and even noisy guys like me)
>  ARE the customers.

>"Noisy guys like me" means I only contributed a couple of patches but I
>still like to think that the some of the ideas I dumped on Jakarta
>lists
>are worth something (hey, some of them did result on something besides 
>flames).

+1  Gotcha.  I missed your meaning before.

> One way or the other, I am involved. I am NO external customer. Even
if
> many times just with ideas, I try to influence and contribute to the 
>evolution of the products I use.

yup.

>And when I see no possibility of changing the product in the way it 
>suites my nee

Re: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Geir Magnusson Jr.]

On 1/6/02 12:56 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> "Geir Magnusson Jr." wrote:
>>> Man, people that want documents in Excel and Word formats ALREADY have the
>>> client software!!! It is called Microsoft Word and Microsoft Excel!
>> 
>> I looked and looked on my linux box, but couldn't find it.  Send me a CD.
> 
> How about saving the postage and downloading a client from here:
> 
> http://www.openoffice.org/

Have you ever used it?

I have.  It was ok.  But didn't read everything.  "Usually" isn't something
I would tell my clients when asked if something I gave them worked :)

> 
> HTTP doesn't care about the format of the documents an application
> renders as a response. HTML is just a default. Applications often render
> images and PDFs dynamically. The same could be done with documents in
> any format. And since the Microsoft formats support hyperlinks, one
> could do an entire Web app that way, and use any client that understood
> the format. (Like the above.)
> 
> So, if XML doesn't care if POI is here or there, and the POI people
> would just as soon have it here, that's fine with me.
> 
> I believe the POI developers have shown that they understand what it
> means to be a ASF product (at least as much as anyone does), and if
> Stefano is willing to re-enlist and help shepard POI into the fold, then
> I say let's move ahead.

Sure, what the hell.  Why not.  +1 from me.  Welcome POI.

We agree to disagree.  You hold the rug, and I'll get the broom...

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Ted Husted]

"Geir Magnusson Jr." wrote:
> > Man, people that want documents in Excel and Word formats ALREADY have the
> > client software!!! It is called Microsoft Word and Microsoft Excel!
> 
> I looked and looked on my linux box, but couldn't find it.  Send me a CD.

How about saving the postage and downloading a client from here:

 http://www.openoffice.org/

HTTP doesn't care about the format of the documents an application
renders as a response. HTML is just a default. Applications often render
images and PDFs dynamically. The same could be done with documents in
any format. And since the Microsoft formats support hyperlinks, one
could do an entire Web app that way, and use any client that understood
the format. (Like the above.)

So, if XML doesn't care if POI is here or there, and the POI people
would just as soon have it here, that's fine with me. 

I believe the POI developers have shown that they understand what it
means to be a ASF product (at least as much as anyone does), and if
Stefano is willing to re-enlist and help shepard POI into the fold, then
I say let's move ahead. 

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Geir Magnusson Jr.]

On 1/6/02 12:58 PM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:

>> -Original Message-
>> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
>> Sent: Sunday, January 06, 2002 6:16 PM
>> 
 Isn't it fair to guess that the majority of your server side
>> use would be
 reading documents for presentation, indexing, searching?
>>> 
>>> WHY for presentation? Most of the time you would batch convert Word and
>>> Excel docs to HTML if needed, and there are specialized tools for that.
>> 
>> 'presentation' in the sense of 'reading data out to show in some manner',
>> not 'on the desktop'.
> 
> Of course, but are you sure it is so clear that POI should mostly be used
> for presentation and indexing?

If you start at the top of the thread, I declare I am playing devils'
advocate, and addressing the three URLs that andrew gave.

I don't think it "should" be used for anything - that's up to the users and
I would never try to make an assertion to that end.

To give you the benefit of the doubt that I wasn't clear, change "would be"
to "currently is" as that is what I meant.

The dissonance that struck me was between the thing that makes POI different
- the ability to write xls files - and what I read to be the most common use
- reading xls for serverside presentation and indexing.

I'm just trying to figure this out.

> 
> 
 However, you point out in the above link that the thing that makes POI
 special is it's ability to *write*?  What's the % of mainly writing to
 mainly reading on the serverside?
>>> 
>>> As mentioned in my previous posting, it is JUST like Velocity writing
>>> HTML.
>>> 
>> 
>> Huh?  You have to explain that a little more - I don't quite get it.
> 
> POI writes Word/Excel formats as Velocity writes HTML.
> 
> The fact that Velocity writes HTML does not make it neither client side
> neither server side - it can be used both ways.

And the whole point of my statement above was that it wasn't the fact that
it writes, but the fact that it writes is what makes it unique (or that is
what I though was said...)

The fact that Velocity can generate HTML doesn't make it special.


> 
>>> 
> http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html
 
 Paulo might use VB to make a client side app, but I wouldn't
>> if I wanted
 portability, especially if I was looking to the handheld or embedded
 application that could access a document remotely...
>>> 
>>> Are there many uses for writing Word/Excel documents in a client-side
>>> device that has not Word or Excel installed???
>> 
>> You might find this unbelieveable, but not everyone works on a
>> computer that runs an operating system that has Word or Excel available.
> 
> And is there many people NOT having Word or Excel installed that care about
> writing Word and Excel documents in a CLIENT device???

YES.  Anyone who uses Linux is an example. (sorry, I've found open-office
and gnumeric don't really cut it...)

> 
> However, of course that I want to write such formats on a SERVER device
> without any MS stuff (Linux), so that clients WITH MS software installed
> can read them.
> 
> 
> Your examples represent rare needs. Not impossible, but quite improbable.
> 
> 
>> ...
> 
> 
> Have fun,
> Paulo Gaspar
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Paulo Gaspar]

> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 06, 2002 6:16 PM
>
> >> Isn't it fair to guess that the majority of your server side
> use would be
> >> reading documents for presentation, indexing, searching?
> >
> > WHY for presentation? Most of the time you would batch convert Word and
> > Excel docs to HTML if needed, and there are specialized tools for that.
>
> 'presentation' in the sense of 'reading data out to show in some manner',
> not 'on the desktop'.

Of course, but are you sure it is so clear that POI should mostly be used
for presentation and indexing?


> >> However, you point out in the above link that the thing that makes POI
> >> special is it's ability to *write*?  What's the % of mainly writing to
> >> mainly reading on the serverside?
> >
> > As mentioned in my previous posting, it is JUST like Velocity writing
> > HTML.
> >
>
> Huh?  You have to explain that a little more - I don't quite get it.

POI writes Word/Excel formats as Velocity writes HTML.

The fact that Velocity writes HTML does not make it neither client side
neither server side - it can be used both ways.

> >
> >>> http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html
> >>
> >> Paulo might use VB to make a client side app, but I wouldn't
> if I wanted
> >> portability, especially if I was looking to the handheld or embedded
> >> application that could access a document remotely...
> >
> > Are there many uses for writing Word/Excel documents in a client-side
> > device that has not Word or Excel installed???
>
> You might find this unbelieveable, but not everyone works on a
> computer that runs an operating system that has Word or Excel available.

And is there many people NOT having Word or Excel installed that care about
writing Word and Excel documents in a CLIENT device???

However, of course that I want to write such formats on a SERVER device
without any MS stuff (Linux), so that clients WITH MS software installed
can read them.


Your examples represent rare needs. Not impossible, but quite improbable.


> ...


Have fun,
Paulo Gaspar


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Peter Donald]

On Mon, 7 Jan 2002 04:14, Geir Magnusson Jr. wrote:
> > BTW, do you know they use Velocity for something???
>
> Who, POI?

Cocoon have a VelocityGenerator (the first stage in their XML transformation 
pipeline).

-- 
Cheers,

Pete

--
you've made a dangerous leap right over common 
sense, like some kind of metaphysical Evil Knievel
--

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Paulo Gaspar]

Again...

> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 06, 2002 6:14 PM
> 
> On 1/6/02 12:11 PM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:
>
> ... Lots of "is it server or is it client" talk ...

I just mean that sometimes saying that something is server-side or 
client-side just makes no sense.

As Ceki puts it, maybe JMeter is one of the few clearly server-side 
products in Jakarta. 

BTW... is Log4J server-side?
=;o)


> >>> From what I read, POI is an API that accesses data in XLS files...
> >>> Theres a huge difference.
> >> 
> >> And Cocoon isn't part of Jakarta, is it? :)
> > 
> > JUST because it is XML centric, which POI is not.
> 
> Right.  I wasn't advocating it going to XML-land - it doesn't 
> seem to belong there either.

It am still not aware of any valid argument that clearly states why
it does not belong to Jakarta or why it belongs.

It is just like BCEL or Log4J - some people wanted those projects here
because they had use for them or were already using them.

Nothing to do with serversideness!!!

  
> > BTW, do you know they use Velocity for something???
> 
> Who, POI?

NO! Cocoon!

> ...
>
Have fun,
Paulo Gaspar


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Geir Magnusson Jr.]

On 1/6/02 12:18 PM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:

> Here we go again,

Alas.

> 
>> -Original Message-
>> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
>> Sent: Sunday, January 06, 2002 4:45 AM
>> 
>> 
>> Playing Devil's advocate.  I think it's fair to push back on adding things
>> to Jakarta...
>> 
>> On 1/5/02 9:53 PM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:
>>> 
>>> Please read these posts and then tell me where you're not clear?
>>> 
>>> http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html
>> 
>> Isn't it fair to guess that the majority of your server side use would be
>> reading documents for presentation, indexing, searching?
> 
> WHY for presentation? Most of the time you would batch convert Word and
> Excel docs to HTML if needed, and there are specialized tools for that.

'presentation' in the sense of 'reading data out to show in some manner',
not 'on the desktop'.

> 
>> However, you point out in the above link that the thing that makes POI
>> special is it's ability to *write*?  What's the % of mainly writing to
>> mainly reading on the serverside?
> 
> As mentioned in my previous posting, it is JUST like Velocity writing
> HTML.
> 

Huh?  You have to explain that a little more - I don't quite get it.

> 
>>> http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html
>> 
>> Paulo might use VB to make a client side app, but I wouldn't if I wanted
>> portability, especially if I was looking to the handheld or embedded
>> application that could access a document remotely...
> 
> Are there many uses for writing Word/Excel documents in a client-side
> device that has not Word or Excel installed???

You might find this unbelieveable, but not everyone works on a computer that
runs an operating system that has Word or Excel available.

> 
> And AFAIK, if you have Word and Excel, you have at least some Basic
> scripting... but maybe you do not have Java.
> 
>> ...
> 
> 
> Have fun,
> Paulo Gaspar
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Geir Magnusson Jr.]

On 1/6/02 12:11 PM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:

> Hi Geir,
> 

Hi Paulo, 

>> -Original Message-
>> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
>> Sent: Sunday, January 06, 2002 4:30 AM
>> 
>> ...
>> 
>>> POI is as client-side as Tomcat is.
>> 
>> Why do you say that?  It is used on the server side, and that's fantastic,
>> but in my opinion (note that I recognize I am  a complete outsider to your
>> project who would be defined as a user) it seems client side.
>> 
>> If I had a need for something like this (and I bet I will at some point),
>> and I had the choice to look at either
>> 
>>   a)  jakarta, the apache java server-side focused project or
>> 
>>   b)  floccinoccinihilipilificator*, the apache java client-side project
> 
> I would you want to have something on the client side besides the browser?

Maybe 'client-side' is the wrong word - thanks for bringing that up.  Its
more like 'user side' (but that still doesn't capture it).

Ant, for example.

Swing stuff.

Client-side stuff for Liberty (the single-sign-on consortium to produce an
alternative to Passport)

Etc

> 
> 
>> I would choose b), as I think of word and excel as a client-side
>> thingy.  No matter that my use is server-side...
> 
> Man, people that want documents in Excel and Word formats ALREADY have the
> client software!!! It is called Microsoft Word and Microsoft Excel!

I looked and looked on my linux box, but couldn't find it.  Send me a CD.

I had the problem where a client wanted to extract data from an xls using
Java.  The solution we were looking at was using automation to do it.  Now I
will look at POI.

And it's not on a server.  I guess that makes me the first one.
 
> 
>> ...
>> 
>>> So is a library that outputs in HTML is clientside or
>>> serverside?
>> 
>> Serverside generally, as the canonical model of HTML use is the web, with
> a
>> clear delineation of server and client.  However, it indeed has clientside
>> uses - take for example any help system that outputs HTML within a
>> monolithic desktop application.
> 
> So, generally with zillions of exceptions.

Yes, but you will agree that the majority of use is server-side?

> 
> 
>> Conversely, I would argue that Excel is a totally client-side technology,
>> and therefore a library that works with XLS files is clientside
>> generally as
>> the canonical model of Excel is on the desktop.  However, it indeed has
>> serverside uses
> 
> That is just like saying that "the HTML browser is totally client-side
> technology (as are HTML editors) and therefore a library that works with
> HTML files is clientside generally".

No... A library that renders HTML streams would be clientside generally.  I
think we need to be specific here

 
> If you go on I will end up getting to the conclusion that Velocity is a
> client
> side tool.

It is in many ways. I try to tell people that every day :)
 
> This kind of definition is BS. Means nothing.
> 
> We are discussing the sex of angels.
>

Certainly might be more fun :)
 
> 
>>> Cocoon publishes documents that are generally read on the client right?
>> 
>> Yes, but it's more than an API, right?  (I don't know much about
> cocoon...)
> 
> IMO it is much more that an API.
> 
> Cocoon can be used a bit like Anakia (as was recently mentioned on this
> list)
> to produce static documents, except that uses XSLT (argh!) for templating
> and
> can produce many output formats (HTML, PDF (via FOP), SVG, graphics (via
> Batik), etc.).
> 
> It also can be used as a Servlet.

Right - that was my understanding, but I don't use it, so I don't know.
What is the majority of use?
 
> 
>>> From what I read, POI is an API that accesses data in XLS files...
>>> Theres a huge difference.
>> 
>> And Cocoon isn't part of Jakarta, is it? :)
> 
> JUST because it is XML centric, which POI is not.

Right.  I wasn't advocating it going to XML-land - it doesn't seem to belong
there either.
 
> BTW, do you know they use Velocity for something???

Who, POI?

 
> 
>> I don't necessarily think that xml.apache.org is the right place either,
>> although I am not a member of that community in any way shape or form, so
>> that opinion is worth the bits through which it was transmitted.
> 
> Ok.
> 
> 
>> I think that a client project peer to jakarta is still the right place, at
>> least worth discussing,  as we have the interesting temporal convergence
> of
>> the proposal of multiple client side projects when java on the client side
>> is becoming a much more interesting space to work.
> 
> I had that opinion, but when I started imagining what I would use it for I
> found that I had LESS client side uses for it than for Velocity!
> =;o)
> 
>>>  ...
> 
> Have fun,
> Paulo Gaspar
> 

Sometimes do!

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Be a giant.  Take giant steps.  Do giant things...


--
To unsubscribe, e-mail:   
For additional command

RE: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Paulo Gaspar]

Here we go again,

> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 06, 2002 4:45 AM
>
>
> Playing Devil's advocate.  I think it's fair to push back on adding things
> to Jakarta...
>
> On 1/5/02 9:53 PM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:
> >
> > Please read these posts and then tell me where you're not clear?
> >
> > http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html
>
> Isn't it fair to guess that the majority of your server side use would be
> reading documents for presentation, indexing, searching?

WHY for presentation? Most of the time you would batch convert Word and
Excel docs to HTML if needed, and there are specialized tools for that.

> However, you point out in the above link that the thing that makes POI
> special is it's ability to *write*?  What's the % of mainly writing to
> mainly reading on the serverside?

As mentioned in my previous posting, it is JUST like Velocity writing
HTML.


> > http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html
>
> Paulo might use VB to make a client side app, but I wouldn't if I wanted
> portability, especially if I was looking to the handheld or embedded
> application that could access a document remotely...

Are there many uses for writing Word/Excel documents in a client-side
device that has not Word or Excel installed???

And AFAIK, if you have Word and Excel, you have at least some Basic
scripting... but maybe you do not have Java.

> ...


Have fun,
Paulo Gaspar


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Paulo Gaspar]

Hi Geir,

> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 06, 2002 4:30 AM
>
> ...
>
> > POI is as client-side as Tomcat is.
>
> Why do you say that?  It is used on the server side, and that's fantastic,
> but in my opinion (note that I recognize I am  a complete outsider to your
> project who would be defined as a user) it seems client side.
>
> If I had a need for something like this (and I bet I will at some point),
> and I had the choice to look at either
>
>   a)  jakarta, the apache java server-side focused project or
>
>   b)  floccinoccinihilipilificator*, the apache java client-side project

I would you want to have something on the client side besides the browser?


> I would choose b), as I think of word and excel as a client-side
> thingy.  No matter that my use is server-side...

Man, people that want documents in Excel and Word formats ALREADY have the
client software!!! It is called Microsoft Word and Microsoft Excel!


> ...
>
> > So is a library that outputs in HTML is clientside or
> > serverside?
>
> Serverside generally, as the canonical model of HTML use is the web, with
a
> clear delineation of server and client.  However, it indeed has clientside
> uses - take for example any help system that outputs HTML within a
> monolithic desktop application.

So, generally with zillions of exceptions.


> Conversely, I would argue that Excel is a totally client-side technology,
> and therefore a library that works with XLS files is clientside
> generally as
> the canonical model of Excel is on the desktop.  However, it indeed has
> serverside uses

That is just like saying that "the HTML browser is totally client-side
technology (as are HTML editors) and therefore a library that works with
HTML files is clientside generally".

If you go on I will end up getting to the conclusion that Velocity is a
client
side tool.

This kind of definition is BS. Means nothing.

We are discussing the sex of angels.


> > Cocoon publishes documents that are generally read on the client right?
>
> Yes, but it's more than an API, right?  (I don't know much about
cocoon...)

IMO it is much more that an API.

Cocoon can be used a bit like Anakia (as was recently mentioned on this
list)
to produce static documents, except that uses XSLT (argh!) for templating
and
can produce many output formats (HTML, PDF (via FOP), SVG, graphics (via
Batik), etc.).

It also can be used as a Servlet.


> >From what I read, POI is an API that accesses data in XLS files...
> > Theres a huge difference.
>
> And Cocoon isn't part of Jakarta, is it? :)

JUST because it is XML centric, which POI is not.

BTW, do you know they use Velocity for something???


> I don't necessarily think that xml.apache.org is the right place either,
> although I am not a member of that community in any way shape or form, so
> that opinion is worth the bits through which it was transmitted.

Ok.


> I think that a client project peer to jakarta is still the right place, at
> least worth discussing,  as we have the interesting temporal convergence
of
> the proposal of multiple client side projects when java on the client side
> is becoming a much more interesting space to work.

I had that opinion, but when I started imagining what I would use it for I
found that I had LESS client side uses for it than for Velocity!
=;o)

> >  ...

Have fun,
Paulo Gaspar


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: On unity and coherence [was Re: [Request For Comment] POI@apache]

[Paulo Gaspar]

Answer inline

> -Original Message-
> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 06, 2002 3:53 AM
> 
> > ...
> >
> >I can not express this POV better than Linus did in posts reported by 
> >this article:
> >http://kerneltrap.org/article.php?sid=398
> >
> >Any corporation "organizizes" things and I do not see better user 
> >understanding there.
> 
> My viewpoint is a bit different then Linus on some things.  

Keep in mind that Linus does not favor complete anarchy, as is obvious
from the grip he has on Linux.

The point is that too many restrictions are bad. The problem is to 
find out what "too many" is.

IMO, things can be improved but the main problem is not lack of rigid 
discipline. 

As an example of "too many" or "too less" restrictions, I believe that:
 - forcing every project to follow the same code conventions would be
   counterproductive;
 - forcing each project to have explicit code conventions and follow 
   them would be just fine.

It is good to have diversity. There is the cross pollination effect and
there is also the fact that what one group things is better is not so 
sure that it should be imposed.

 
> >Besides, there is no such thing as an Open Source external customer. 
> >Those that contribute to it (the authors and even noisy guys like me)
> >ARE the customers.
> 
> >People PAY Open Source by participating. If something is wrong FIX IT!
> 
> I don't completely agree with you on that.  Some contributions to Open
> Source are less quantifiable than others.  I see I'm a bit
> morecommunistic.  I'm so far the the left on this that I'm on the
> right?  

I doubt you are that different.

 
> >(Ok! I confess I learned this stuff mostly from Jon.)
> 
> >If you do not like an Open Source product as it is, contribute (fight)
> >to change it. If most of the project owners do not let you, FORK. At 
> >least you can learn a lot and save a lot of work.
> 
> I try to keep people happy.  If they want to contribute something that
> is not withing to POI's mission, that won't fly.  (There will be NO GUI
> components in POI)... If they feel like working on a feature that I just
> don't think is in our critical path...go at it.  

So, you try to keep people happy but you are not so communistic that you
make everybody happy (which would be crazy, I agree).

 
> Anyhow I contributed ideas.  Take them for what they were.  They were
> NOT complaints.  Apache is the most healthy opensource group there is.
> 
> (its healthier then GNU IMHO)

I also believe so, of course.

 
> >You probably know what I am talking about since POI is Open Source.
> 
> POI is opensource, there are some differences of opinion between you and
> I on who the "contributers" are.  To me:
> 
> User: doesn't submit patches, but uses the software.  The more people
> who USE POI the better and healthier POI is.
> 
>For example.  A user the other day sent a bug.  He had an toasted XLS
>file.  It had confidential data in it so he couldn't contribute a
>sample.  I talked him through running HSSF through a debugger and he
>found the problem.  HSSF 1.0.1 can't handle cells with strings over  
>15,000 characters long if they don't occur early in the file.  (there
>is a static string table and it is kinda blocked or paged).

You are talking about users that contribute something to the projects: 
they test it, report problems and help making it more solid that way.

I still do not see any difference in your opinion.

In my posting I even including this paragraph:
  Besides, there is no such thing as an Open Source external customer. 
  Those that contribute to it (the authors and even noisy guys like me)
  ARE the customers.

"Noisy guys like me" means I only contributed a couple of patches but I
still like to think that the some of the ideas I dumped on Jakarta lists
are worth something (hey, some of them did result on something besides 
flames).

One way or the other, I am involved. I am NO external customer. Even if
many times just with ideas, I try to influence and contribute to the 
evolution of the products I use.

And when I see no possibility of changing the product in the way it 
suites my needs, I fork and still save a lot of work.

 
> Developer: writes java code or documentation or examples etc for POI
> 
> ...
>
> >For complex enough software, Winston Churchill's remarks about
> >democracy
> >apply quite well to Open Source as we know it by rephrasing them a bit:
> >
> > "Open Source is the worse form of developing complex software, except
> >
> >  all those others that have been tried."
> >
> >(
> 
> One of the cool things about both is the free expression of idea.  Those
> were mine.  Like I said.  Thoughts.  I like open source.  I do open
> source.  I use open source.  I don't think its perfect and there are
> additional things I do that don't happen in most open source projects
> (like documentation ;-) and modeling the hard stuff), but thats a
> differen

Re: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Geir Magnusson Jr.]

Playing Devil's advocate.  I think it's fair to push back on adding things
to Jakarta...

On 1/5/02 9:53 PM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:
> 
> Please read these posts and then tell me where you're not clear?
> 
> http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html

Isn't it fair to guess that the majority of your server side use would be
reading documents for presentation, indexing, searching?  However, you point
out in the above link that the thing that makes POI special is it's ability
to *write*?  What's the % of mainly writing to mainly reading on the
serverside?


> http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html

Paulo might use VB to make a client side app, but I wouldn't if I wanted
portability, especially if I was looking to the handheld or embedded
application that could access a document remotely...

> http://www.mail-archive.com/general%40jakarta.apache.org/msg02690.html

No comment, as it's an agreeable followup to the above.

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"We will be judged not by the monuments we build, but by the monuments we
destroy" - Ada Louise Huxtable


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Geir Magnusson Jr.]

On 1/5/02 9:53 PM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:

> On 1/5/02 7:28 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:
> 
> 
>> I am not trying to be combative - I have watched this thread (and
>> participated) with growing discomfort.  I have to say that I think that
>> bringing XML and Jakarta together might destroy the thing we are
>> supposedly
>> trying to 'save' (again, I don't get the problem...), namely the
>> community
>> that each group has.  Larger isn't always better.
> 
> I kinda agree with you on that.

Ted didn't write that.  I did.


> 
 I also think we are more than ready for a POI vote, if someone were
> to
>>> post an actual proposal, including the list of committers.
>>> In that proposal, can it be argued why it belongs here?  I have tried
>> to sit
>> on the fence, and I am glad Stefano will step up to champion the
>> project,
>> but I also think that if he scope of Jakarta is confusing now, adding a
>> vendor-specific desktop document API (granted, with server-side uses)
>> will
>> add to it.
> 
>> There was recent talk for other "clearly client" projects to be added,
>> with
>> the same apparent quality of code and health of community - why not
>> bundle
>> the two as a seed for a new Apache client-focused project to be a peer
>> to
>> jakarta and XML and ...?  If you have used any of the pure Java IDE's
>> lately, it's clear that Java has indeed matured enough for use on the
>> desktop, and initiatives on other client-side devices such as phones,
>> PDA's,
>> etc make for a very rich opportunity for Apache.  Further, meta-API
>> initiatives like Liberty which span both server and client (of all
>> types)
>> are clearly in Apache's interest, so I believe that a client-focused
>> Apache
>> project is appropriate for that reason as well.
> 

I also wrote that, not Ted.

> 
> Maybe its not yet time for a vote.  Let me state this again and make it
> very clear.  POI has many users and many uses.  No one I know of is
> using POI on the client.

Maybe you have some marketing problems? :)

> POI is as client-side as Tomcat is.

Why do you say that?  It is used on the server side, and that's fantastic,
but in my opinion (note that I recognize I am  a complete outsider to your
project who would be defined as a user) it seems client side.

If I had a need for something like this (and I bet I will at some point),
and I had the choice to look at either

  a)  jakarta, the apache java server-side focused project or
 
  b)  floccinoccinihilipilificator*, the apache java client-side project


I would choose b), as I think of word and excel as a client-side thingy.  No
matter that my use is server-side...


> (Tomcat is
> used by Netbeans a pure Java-IDE on the client!).  HTML is for use on
> the client right?

Yep.  But its a markup definition, not an API implementation.

> So is a library that outputs in HTML is clientside or
> serverside? 

Serverside generally, as the canonical model of HTML use is the web, with a
clear delineation of server and client.  However, it indeed has clientside
uses - take for example any help system that outputs HTML within a
monolithic desktop application.

Conversely, I would argue that Excel is a totally client-side technology,
and therefore a library that works with XLS files is clientside generally as
the canonical model of Excel is on the desktop.  However, it indeed has
serverside uses


> Cocoon publishes documents that are generally read on the
> client right? 

Yes, but it's more than an API, right?  (I don't know much about cocoon...)

>From what I read, POI is an API that accesses data in XLS files...  Theres a
huge difference.

And Cocoon isn't part of Jakarta, is it? :)

I don't necessarily think that xml.apache.org is the right place either,
although I am not a member of that community in any way shape or form, so
that opinion is worth the bits through which it was transmitted.

I think that a client project peer to jakarta is still the right place, at
least worth discussing,  as we have the interesting temporal convergence of
the proposal of multiple client side projects when java on the client side
is becoming a much more interesting space to work.

> 
> Please read these posts and then tell me where you're not clear?
> 
> http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html
> http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html
> http://www.mail-archive.com/general%40jakarta.apache.org/msg02690.html

I will.

> 
> POI::HSSF reads or generates XLS files and is nearly always used on the
> server .  OF all POI's users not one person is using it on the client.
> Please check out http://poi.sourceforge.net.  The page describes its
> usage

I will.

Note I spent years supporting Excel 'stuff' in the financial industry as
part of a project I led, and every user I knew was client-side.  You may
just be ahead of your time :)


-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
Syst

Re: On unity and coherence [was Re: [Request For Comment] POI@apache]

[Andrew C. Oliver]

On 1/5/02 7:28 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:


>I am not trying to be combative - I have watched this thread (and
>participated) with growing discomfort.  I have to say that I think that
>bringing XML and Jakarta together might destroy the thing we are
>supposedly
>trying to 'save' (again, I don't get the problem...), namely the
>community
>that each group has.  Larger isn't always better.

I kinda agree with you on that.

>> > I also think we are more than ready for a POI vote, if someone were
to
>> post an actual proposal, including the list of committers.
>> In that proposal, can it be argued why it belongs here?  I have tried
>to sit
>on the fence, and I am glad Stefano will step up to champion the
>project,
>but I also think that if he scope of Jakarta is confusing now, adding a
>vendor-specific desktop document API (granted, with server-side uses)
>will
>add to it.

>There was recent talk for other "clearly client" projects to be added,
>with
>the same apparent quality of code and health of community - why not
>bundle
>the two as a seed for a new Apache client-focused project to be a peer
>to
>jakarta and XML and ...?  If you have used any of the pure Java IDE's
>lately, it's clear that Java has indeed matured enough for use on the
>desktop, and initiatives on other client-side devices such as phones,
>PDA's,
>etc make for a very rich opportunity for Apache.  Further, meta-API
>initiatives like Liberty which span both server and client (of all
>types)
>are clearly in Apache's interest, so I believe that a client-focused
>Apache
>project is appropriate for that reason as well.


Maybe its not yet time for a vote.  Let me state this again and make it
very clear.  POI has many users and many uses.  No one I know of is
using POI on the client.  POI is as client-side as Tomcat is. (Tomcat is
used by Netbeans a pure Java-IDE on the client!).  HTML is for use on
the client right?  So is a library that outputs in HTML is clientside or
serverside?  Cocoon publishes documents that are generally read on the
client right? 

Please read these posts and then tell me where you're not clear?

http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html
http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html
http://www.mail-archive.com/general%40jakarta.apache.org/msg02690.html

POI::HSSF reads or generates XLS files and is nearly always used on the
server .  OF all POI's users not one person is using it on the client. 
Please check out http://poi.sourceforge.net.  The page describes its
usage


-Andy

-- 
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: On unity and coherence [was Re: [Request For Comment] POI@apache]

[Andrew C. Oliver]

>Hi Andrew,


>Before trying to "organizize" too much how Open Source development
>works,
>maybe you should consider that impositions of organization and
>discipline
>could kill the Golden Eggs Chicken.

>I can not express this POV better than Linus did in posts reported by 
>this article:
>http://kerneltrap.org/article.php?sid=398


>Any corporation "organizizes" things and I do not see better user 
>understanding there.

My viewpoint is a bit different then Linus on some things.  

>Besides, there is no such thing as an Open Source external customer. 
>Those that contribute to it (the authors and even noisy guys like me)
>ARE the customers.

>People PAY Open Source by participating. If something is wrong FIX IT!

I don't completely agree with you on that.  Some contributions to Open
Source are less quantifiable than others.  I see I'm a bit
morecommunistic.  I'm so far the the left on this that I'm on the
right?  


>(Ok! I confess I learned this stuff mostly from Jon.)

>If you do not like an Open Source product as it is, contribute (fight)
>to change it. If most of the project owners do not let you, FORK. At 
>least you can learn a lot and save a lot of work.

I try to keep people happy.  If they want to contribute something that
is not withing to POI's mission, that won't fly.  (There will be NO GUI
components in POI)... If they feel like working on a feature that I just
don't think is in our critical path...go at it.  

Anyhow I contributed ideas.  Take them for what they were.  They were
NOT complaints.  Apache is the most healthy opensource group there is.

(its healthier then GNU IMHO)

>You probably know what I am talking about since POI is Open Source.

POI is opensource, there are some differences of opinion between you and
I on who the "contributers" are.  To me:

User: doesn't submit patches, but uses the software.  The more people
who USE POI the better and healthier POI is.

   For example.  A user the other day sent a bug.  He had an toasted XLS
   file.  It had confidential data in it so he couldn't contribute a
   sample.  I talked him through running HSSF through a debugger and he
   found the problem.  HSSF 1.0.1 can't handle cells with strings over  
   15,000 characters long if they don't occur early in the file.  (there
   is a static string table and it is kinda blocked or paged).

Developer: writes java code or documentation or examples etc for POI

committer: is the lowest form of life (like me) on POI..  :-D  (J/K)  If
someone develops too much they are demoted to a committer then they have
to deal with CVS :-p

>For complex enough software, Winston Churchill's remarks about
>democracy
>apply quite well to Open Source as we know it by rephrasing them a bit:
>
> "Open Source is the worse form of developing complex software, except
>
>  all those others that have been tried."
>
>(

One of the cool things about both is the free expression of idea.  Those
were mine.  Like I said.  Thoughts.  I like open source.  I do open
source.  I use open source.  I don't think its perfect and there are
additional things I do that don't happen in most open source projects
(like documentation ;-) and modeling the hard stuff), but thats a
different story. 

>The original Winston Churchill quote:
>Many forms of Government have been tried, and will be tried in this 
>world of sin and woe. No one pretends that democracy is perfect or 
>all-wise. Indeed, it has been said that democracy is the worst form of 
>Government except all those others that have been.
>)

Exactly

>Relax and have fun, organic growing works or we wouldn't be here!

organic growing can happen outside of open source.  
open source can be inorganic.
Like I said they were random thoughts in RESPONSE to messages.  I didn't
say anything in particular was busted, I stated some viewpoints I'd read
and stated some problems that exist and some things I thought could help
improve them.  Thats all.

-Andy

Paulo Gaspar

-- 
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Ted Husted]

"Geir Magnusson Jr." wrote:
> > It's my understanding that Apache Projects' unity of purpose is
> >
> > "to encourage a collaborative, consensus-based development process"
> 
> What does that exactly mean?

Perhaps Stefano's original preamble said it best

http://java.apache.org/main/constitution.html

"Unlike other open source projects where an individual rules the project
as a benevolent dictator, the Java Apache Project form is government is
based on merit: everyone who deserves it get the right to vote and
everyone who is able to vote participates in the ruling of the project.
This kind of  government helps in maintaining the project going even
when core individuals leave the project or don't have enough time. The
project itself is like the ancient Greek Agora idea, where everybody
helps and who deserves it decide. This meritocracy allows the project to
be very flexible toward people presence and allows fast and safe changes
in the core group since who decides is always who is more involved and
cares the most. "

I believe that everything else here, the projects, the subprojects, are
just a means to serve the end of development by meritocracy. 


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI@apache]

[Ted Husted]

"Andrew C. Oliver" wrote:
> Thats very high minded and a great mission statement in many respects.
> I still say adding unity-of-purpose to Jakarta and creating some more
> user-minded-distributions of things would be helpful from a user
> perspective.

If creating more user-minded-distributions is something a developer
enjoys, then that's what a developer should do. The developers are
creating software that meets their needs, and freely sharing it with
others. But those others don't drive the development process. The
developers do.

A commercial enterprise may have the goal of winning the most users,
since users contribute to the development process through the payment of
fees. But I do not see that as the goal of Apache Projects. If (in some
impossible way) our software were inferior, and our developers
miserable, then Apache would be a failure no matter how many people used
the software. 

What is amazing is that Apache Projects have so many users, without
spending a single dime on marketing, or payroll, or anything but a
development and distribution infrastructure. 

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Paulo Gaspar]

Hi Andrew,


Before trying to "organizize" too much how Open Source development works,
maybe you should consider that impositions of organization and discipline
could kill the Golden Eggs Chicken.

I can not express this POV better than Linus did in posts reported by 
this article:
http://kerneltrap.org/article.php?sid=398


Any corporation "organizizes" things and I do not see better user 
understanding there.


Besides, there is no such thing as an Open Source external customer. 
Those that contribute to it (the authors and even noisy guys like me)
ARE the customers.

People PAY Open Source by participating. If something is wrong FIX IT!

(Ok! I confess I learned this stuff mostly from Jon.)


If you do not like an Open Source product as it is, contribute (fight)
to change it. If most of the project owners do not let you, FORK. At 
least you can learn a lot and save a lot of work.

You probably know what I am talking about since POI is Open Source.


For complex enough software, Winston Churchill's remarks about democracy
apply quite well to Open Source as we know it by rephrasing them a bit:

  "Open Source is the worse form of developing complex software, except 
  all those others that have been tried."

(
The original Winston Churchill quote:
Many forms of Government have been tried, and will be tried in this 
world of sin and woe. No one pretends that democracy is perfect or 
all-wise. Indeed, it has been said that democracy is the worst form of 
Government except all those others that have been.
)


Relax and have fun, organic growing works or we wouldn't be here!
Paulo Gaspar



> -Original Message-
> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 06, 2002 1:01 AM
> To: [EMAIL PROTECTED]
> Subject: Re: On unity and coherence [was Re: [Request For Comment] POI
> @apache]
> 
> 
> Not that I should have much of a role in this discussion but I'd like to
> contribute some thoughts stemming from an offline discussion I had.
> 
> I think this discussion is still missing the point.  There are a lot of
> outsider articles on "what is wrong with Apache" these days, most of
> them refer to the total disinterest (by many developers in the projects)
> on "the market" meaning what do the user's actually want.  I'd say this
> is a component.  (Please take this as somewhat of an outsider who has a
> lot of experience with Apache work-products)  (as a symptom of this:
> Apache is OBVIOUSLY a better Web Server, TOMCAT is obviously a better
> App server of sorts, and though not a apache project JBOSS is a great
> enterprise serverso why is IIS gaining ground despite its overall
> suckiness?)
> 
> The second component is an overall lack of unity-of-purpose. 
> XML.apache.org hasn't reached a critical mass and in my opinion may
> never because it does have unity-of-purpose and I think that is part of
> why Stefano recommended I approach Jakarta first.  
> 
> POI has a lot to contribute to XML.apache.org but it has a lot of stuff
> that *would* contribute more to Jakarta's purpose if it had one.  This
> isn't a slam, hear me out. 
> 
> The Apache group had a unity of purpose early on.  They had a product: a
> webserver.  Everything that Apache did had something directly to do with
> that product.  Some things were semi-independent so subgroups seemed
> like the best way to handle it.  
> 
> Java-Apache had this unity-of-purpose:  Java on Apache.  Well for Java
> on Apache you need a mod to handle that (since everything is a mod in
> Apache) so you get mod-jserv, of course you have a lot of things that
> roll in and out of that based on serverside components for developing
> with your java mod.  But you have unity-of-purpose. (or at least for a
> time)
> 
> What is Jakarta's mission?  "server side java" stuff.  What is your
> product (look at the homepage)whoa thats a big list of
> subprojects...  Wait is ant a server side java tool?  Well..kinda sorta
> (build server)... what kind of server-side java stuff.
> 
> XML.apache.org has a few well-defined "products" with the "main" one
> being Cocoon.  This may change slightly as the web services thing comes
> to a head (as the speaker coordinator for my JUG www.trijug.org I can
> tell you this is coming to a head) and more web-servicey things happen
> with XML rather than publishing (Cocoon) and maybe at that time there
> should be a webservices.apache.org (and webservices will expand beyond
> XML), but for the moment you've got real products and a
> unity-of-purpose.  (Which parts of POI fit well into..the cocoon 2
> serializers for instance and others do not)
> 
> So what do most people (users) come to Jakarta for?  Tomca

Re: On unity and coherence [was Re: [Request For Comment] POI@apache]

[Andrew C. Oliver]

>"Andrew C. Oliver" wrote:
>> > Not that I should have much of a role in this discussion but I'd
>like to
>> contribute some thoughts stemming from an offline discussion I had.



>These are very thoughtful commnents, Andrew, I hope you post again. 

Thanks.  Perhaps, this list is a little high traffic at the moment for
me to keep up with everything.

>It's my understanding that Apache Projects' unity of purpose is 
>"to encourage a collaborative, consensus-based development process"
>The rest is syntatic sugar.

Thats very high minded and a great mission statement in many respects. 
I still say adding unity-of-purpose to Jakarta and creating some more
user-minded-distributions of things would be helpful from a user
perspective.

>For the record, I do believe the PMC members took the high-road when
>discussing the code conventions. The few posts about things like braces
>looked like jokes to me. Most of the conversation was about whether we
>should keep the conventions we have, and having them, how do we promote
>their use. 

Maybe I missed some of those posts.  I was a bit incensed by one message
where a developer's commit was actually singled out and criticized
publicly for using "_variables" (I don't use that style personally, but
someone I respect greatly does).   Perhaps I missed the joke on that (a
personal public flogging).  I can be dense, but my brain is frozen and
I'm not used to that (SE US got snowed over).

>Personally, I don't think Apache or Jakarta are broken. We create great
>products, and have fun doing it. AFAIK, that's our only mission.

Hopefully, I did not go as far to say they were broken.  My response was
based on previous emails that were saying they've exceeded critical
mass.  If I implied they were "broken" then I misspoke.  I did not mean
to criticize that strongly.  What I meant to get across was that a minor
course correction would be in order.  I meant to suggest bringing
greater unity of purpose as I outlined would alleviate some of the
outside and inside perceived problems.

>We do need more internal documentation, since it does takes some effort
>to get up to speed here, and volunteers to help with this are always
>welcome.

Thats a chicken and the egg problem.  Contributing to the documentation
requires often an understanding that the people most interested in
improving the documentation probably don't have ;-p.  I'll be doing what
I can in the near future.  I need to get up to speed on docbook and the
such and then I'll start sending a harassing flux of patches to the
projects that I find have the most egregious documentation (or lack of)
and jump up and down until committers commit them (and when they flame
me I'll say Ted told me to :-p j/k).  But at the moment I'm drowning in
email from the POI 1.0 release (there is nothing like a release to find
actual bugs and drum up new requirements and ideas) ;-p this should get
better in a few weeks after the initial fury dies down.

>I also think we are more than ready for a POI vote, if someone were to
>post an actual proposal, including the list of committers. 

Okay.  I'd drafted one.  I'll clean it up and post it.  

-Andy



>-Ted.



-- 
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Geir Magnusson Jr.]

On 1/5/02 7:28 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> "Andrew C. Oliver" wrote:
>> 
>> Not that I should have much of a role in this discussion but I'd like to
>> contribute some thoughts stemming from an offline discussion I had.
> 
> 
> 
> These are very thoughtful commnents, Andrew, I hope you post again.
> 
> It's my understanding that Apache Projects' unity of purpose is
> 
> "to encourage a collaborative, consensus-based development process"

What does that exactly mean?

> 
> The rest is syntatic sugar.
>

Really?  Being flip for a moment to illustrate a point, can the 'development
process' apply to real estate?  Photographic film?

In our case, it doesn't. I always assume that it means software, in
jakarta's case software written in Java (and orbiting relations like the
native connectors for Tomcat)  making any further definitions to what you
say the unity of purpose to be more than syntactic sugar.

 
> For the record, I do believe the PMC members took the high-road when
> discussing the code conventions. The few posts about things like braces
> looked like jokes to me. Most of the conversation was about whether we
> should keep the conventions we have, and having them, how do we promote
> their use. 


I have to admit I never understood what the issue was that sparked it - what
problem were we trying to solve?

 
> Personally, I don't think Apache or Jakarta are broken. We create great
> products, and have fun doing it. AFAIK, that's our only mission.
> 

+1

I agree with you 100% that this should be the misson.

Although that doesn't jive with your claim of our unity of purpose above
which simply qualifies a development process.

I am not trying to be combative - I have watched this thread (and
participated) with growing discomfort.  I have to say that I think that
bringing XML and Jakarta together might destroy the thing we are supposedly
trying to 'save' (again, I don't get the problem...), namely the community
that each group has.  Larger isn't always better.


> We do need more internal documentation, since it does takes some effort
> to get up to speed here, and volunteers to help with this are always
> welcome.
> 
> I also think we are more than ready for a POI vote, if someone were to
> post an actual proposal, including the list of committers.
> 

In that proposal, can it be argued why it belongs here?  I have tried to sit
on the fence, and I am glad Stefano will step up to champion the project,
but I also think that if he scope of Jakarta is confusing now, adding a
vendor-specific desktop document API (granted, with server-side uses) will
add to it.

There was recent talk for other "clearly client" projects to be added, with
the same apparent quality of code and health of community - why not bundle
the two as a seed for a new Apache client-focused project to be a peer to
jakarta and XML and ...?  If you have used any of the pure Java IDE's
lately, it's clear that Java has indeed matured enough for use on the
desktop, and initiatives on other client-side devices such as phones, PDA's,
etc make for a very rich opportunity for Apache.  Further, meta-API
initiatives like Liberty which span both server and client (of all types)
are clearly in Apache's interest, so I believe that a client-focused Apache
project is appropriate for that reason as well.


-- 
Geir Magnusson Jr.   [EMAIL PROTECTED]
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Paulo Gaspar]

Biting the bait:

Maybe you and me are following different lists Jon.

AFAIK there is cooperation between Tomcat 3x and Tomcat 4x people.

I sure hope we will have a Tomcat 4 at least as nice to use as 3.3 is
at the moment. I am sure that most Tomcat 3.x users will upgrade as
soon as they feel confident about that being the case. It is possible
that many already did it.

Most 3.3 supporters have no emotional attachments to either the 3.3 or
the 4.x code base. Many of us just believed 3.3 was the shortest path
to a production quality Tomcat.

_Maybe_ there was more people with other interests on the 4.x side.

Either way, the main focus is on 4.x now and I do not see any ongoing 
flame wars on the Tomcat lists. Everybody wants its success.


IMO it is better to stop feeding the flaming and let it die.


Have fun,
Paulo Gaspar


> -Original Message-
> From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 06, 2002 12:37 AM
> To: [EMAIL PROTECTED]
> Subject: Re: On unity and coherence [was Re: [Request For Comment] POI
> @apache]
> 
> 
> on 1/5/02 3:02 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
> 
> > Look closely, Xerces 2 is the designated successor to *both* 
> Xerces 1 and
> > Crimson.  The developers *are* working together.  I won't pretend that
> > everything is 100% smooth sailing, but significant progress is 
> being made.
> 
> Yea...just like Tomcat 3x and Tomcat 4x...suuueee...
> 
> -jon


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

Re: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Ted Husted]

"Andrew C. Oliver" wrote:
> 
> Not that I should have much of a role in this discussion but I'd like to
> contribute some thoughts stemming from an offline discussion I had.



These are very thoughtful commnents, Andrew, I hope you post again. 

It's my understanding that Apache Projects' unity of purpose is 

"to encourage a collaborative, consensus-based development process"

The rest is syntatic sugar.

For the record, I do believe the PMC members took the high-road when
discussing the code conventions. The few posts about things like braces
looked like jokes to me. Most of the conversation was about whether we
should keep the conventions we have, and having them, how do we promote
their use. 

Personally, I don't think Apache or Jakarta are broken. We create great
products, and have fun doing it. AFAIK, that's our only mission.

We do need more internal documentation, since it does takes some effort
to get up to speed here, and volunteers to help with this are always
welcome.

I also think we are more than ready for a POI vote, if someone were to
post an actual proposal, including the list of committers. 

-Ted.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Andrew C. Oliver]

Not that I should have much of a role in this discussion but I'd like to
contribute some thoughts stemming from an offline discussion I had.

I think this discussion is still missing the point.  There are a lot of
outsider articles on "what is wrong with Apache" these days, most of
them refer to the total disinterest (by many developers in the projects)
on "the market" meaning what do the user's actually want.  I'd say this
is a component.  (Please take this as somewhat of an outsider who has a
lot of experience with Apache work-products)  (as a symptom of this:
Apache is OBVIOUSLY a better Web Server, TOMCAT is obviously a better
App server of sorts, and though not a apache project JBOSS is a great
enterprise serverso why is IIS gaining ground despite its overall
suckiness?)

The second component is an overall lack of unity-of-purpose. 
XML.apache.org hasn't reached a critical mass and in my opinion may
never because it does have unity-of-purpose and I think that is part of
why Stefano recommended I approach Jakarta first.  

POI has a lot to contribute to XML.apache.org but it has a lot of stuff
that *would* contribute more to Jakarta's purpose if it had one.  This
isn't a slam, hear me out. 

The Apache group had a unity of purpose early on.  They had a product: a
webserver.  Everything that Apache did had something directly to do with
that product.  Some things were semi-independent so subgroups seemed
like the best way to handle it.  

Java-Apache had this unity-of-purpose:  Java on Apache.  Well for Java
on Apache you need a mod to handle that (since everything is a mod in
Apache) so you get mod-jserv, of course you have a lot of things that
roll in and out of that based on serverside components for developing
with your java mod.  But you have unity-of-purpose. (or at least for a
time)

What is Jakarta's mission?  "server side java" stuff.  What is your
product (look at the homepage)whoa thats a big list of
subprojects...  Wait is ant a server side java tool?  Well..kinda sorta
(build server)... what kind of server-side java stuff.

XML.apache.org has a few well-defined "products" with the "main" one
being Cocoon.  This may change slightly as the web services thing comes
to a head (as the speaker coordinator for my JUG www.trijug.org I can
tell you this is coming to a head) and more web-servicey things happen
with XML rather than publishing (Cocoon) and maybe at that time there
should be a webservices.apache.org (and webservices will expand beyond
XML), but for the moment you've got real products and a
unity-of-purpose.  (Which parts of POI fit well into..the cocoon 2
serializers for instance and others do not)

So what do most people (users) come to Jakarta for?  Tomcat.  Why?  Go
to the front page.  A big rattled on list of componentsIf I don't
know what I'm looking for suffice to say I won't find it.  If I say
"Tomcat" the general IT population knows what I'm talking about.  (and
the rest know what I mean if I say "the successor to JServ)

Here's my 2c worth (and unless asked its the only thing I'll contribute
to this discussion):

Defined unity of purpose: sever side java is now too fuzzy of a
mission...what are your products and categorize them:

application server (tomcat)
build and development tools (ant/log4j/etc)
document management and publishing (lucene, POI, etc)
application frameworks (avalon, struts)

The Apache brand is worth a lot.  You say Linux in a corporate
environment you get a dirty look (once upon a time we just said
"Solaris-clone" and installed linux to avoid political battles ;-) ),
you say Apache you get a less dirty look.  (You're still a radical but
IBM and Sun said you're an okay radical).

Jakarta needs to do some actual PROJECT work.  Go in and pull these
disparate components into distributions (Redhat doesn't point you to
their website to download X, and then GLIB and go try and put it
together yourself...not that Jakarta should be redhat, but the point
being having distributions).  This helps create unity of purpose as
things start going into distributions and distributions generate
"requirements" and "needs" which roll into features.

> I think this equation misses the important second order affects of
> collaboration.

>My feeling is that communities need a critical mass, as do
>meta-communities.  I'm not sure what that size is, but in my mind the
>XML
>project has not reached it.  And it is not just size that is the issue,
>it
>is the presence (or lack) of people who cross pollinate ideas.  Within
>Jakarta, this is being done on an ever increasing scale.

I think you need to have points.  Both to discussions and to work.  In
the POI project.  Try this:  submit to the poi-devel list (and Marc, Ken
and "the lurkers" may not be monitoring so the experiment would be fair)
a proposal or patch to do something obviously outside of POI's mission
(crack those MS file formats right open, provide apis and XML publishing
utils for those formats)  I bet you yo

Re: On unity and coherence [was Re: [Request For Comment] POI @apache]

[Jon Scott Stevens]

on 1/5/02 3:02 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Look closely, Xerces 2 is the designated successor to *both* Xerces 1 and
> Crimson.  The developers *are* working together.  I won't pretend that
> everything is 100% smooth sailing, but significant progress is being made.

Yea...just like Tomcat 3x and Tomcat 4x...suuueee...

-jon


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]

[Ceki Gülcü]

At 18:02 05.01.2002 -0500, you wrote:
>Ceki Gülcü wrote:
>>
>> IMHO, XML does not and will never have a community as long as two of
>> its most important projects directly compete with each other. The
>> success of one is related with the failure of the other. XML
>> Community? Won't happen in a million years. How the did Crimson
>> become an Apache project anyway?
>
>Look closely, Xerces 2 is the designated successor to *both* Xerces 1 and
>Crimson.  The developers *are* working together.  I won't pretend that
>everything is 100% smooth sailing, but significant progress is being made.

Point well taken.

>> The required majority for the adoption of proposals can be simple or
>> qualified. Even if the qualified majority is 3/4, this would be better
>> than the veto system we have today. Although a veto can be overridden
>> by a 3/4 majority, as far as I know, this has never happened in the
>> past.  Today someone voting -1 means end of discussion.
>>
>> I dare anyone to -1 that. Regards, Ceki
>
>The rules you describe don't look familiar to me.  The ones I am familiar
>with are:
>
>http://jakarta.apache.org/site/decisions.html
>http://jakarta.apache.org/site/management.html

My mistake. I was always under the impression that new project creation
required a 3/4 vote *and* no binding vetoes (which I admit makes no sense).
Thanks for the clarification. Ceki



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]

[Sam Ruby]

Ceki Gülcü wrote:
>
> IMHO, XML does not and will never have a community as long as two of
> its most important projects directly compete with each other. The
> success of one is related with the failure of the other. XML
> Community? Won't happen in a million years. How the did Crimson
> become an Apache project anyway?

Look closely, Xerces 2 is the designated successor to *both* Xerces 1 and
Crimson.  The developers *are* working together.  I won't pretend that
everything is 100% smooth sailing, but significant progress is being made.

> The required majority for the adoption of proposals can be simple or
> qualified. Even if the qualified majority is 3/4, this would be better
> than the veto system we have today. Although a veto can be overridden
> by a 3/4 majority, as far as I know, this has never happened in the
> past.  Today someone voting -1 means end of discussion.
>
> I dare anyone to -1 that. Regards, Ceki

The rules you describe don't look familiar to me.  The ones I am familiar
with are:

http://jakarta.apache.org/site/decisions.html
http://jakarta.apache.org/site/management.html

- Sam Ruby


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]

[Ceki Gülcü]

Chris,

I think you are confusing project categorization with project community. These things
are very much unrelated. Regards, Ceki

At 23:44 05.01.2002 +0100, you wrote:
>Hello,
>Each structure has a cost depending on his level of organization. I think
>there is today to many project in the jakarta and the xml project. I feel
>confuse about finding the right information at the right place. And I think
>it's high time to merge xml and jakarta.
>The way java is organizing code in package is rather simple and efficient,
>maybe organizing project this way is the solution.
>We should debate about this organization.
>I propose some package organization :
>
>XML(Xerces,Crimson)
>XSL(Xalan,FOP)
>SVG(Batik)
>WebApps(Cocoon, JetSpeed...)
>JSP (TagLibs)
>FrameWork(Turbine, Avalon, Struts..)
>Project Management (Ant, Slide)
>Metric & Testing (Log4J, WatchDog)
>ToolBox(ORO, RegExp, Lucene)
>...
>I'd like your opinion about it, which package with which existing project.
>
>Ciao
>Chris
>-
>agitateur depuis toujours
>***
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 

--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]

[Ceki Gülcü]

At 15:31 05.01.2002 +0100, Stefano Mazzocchi wrote:
[Snip]


>In my mind, all this long trail of thoughs yields the following
>equation:
>
> metacommunity size * community coherence * individual freedom = constant

This equation is misleading. Coherence and individual freedom are 
not inversely proportional, perhaps related but not inversely 
proportional. That much is certain. 
  
>in result, if we unify the two projects, we double the size of the
>metacommunity and we must pay the price of decreased coherence and/or
>decreased individual freedom.

>But are we sure the pros outweight the cons?

No, we can't be sure. The experiment cannot be undone and started
over. 

Anyway, contrary to my previous hints, I am unsure if having XML and
Jakarta would benefit either Jakarta or XML. If someone cares enough
about a particular XML project nothing keeps him/her from participating 
in that project.

IMHO, XML does not and will never have a community as long as two of
its most important projects directly compete with each other. The
success of one is related with the failure of the other. XML
Community? Won't happen in a million years. How the did Crimson
become an Apache project anyway?

Unity and coherence (the subject of this thread) are strongly related to
management and decision making. Since we don't have a manager, we must
have a healthy decision making process.

The current system of voting where each participant is granted veto
power is a system geared towards non-decision making. This was perhaps
one of the intentions of the founders of the ASF. Anyone know where -1
tradition came from?

My suggestion is institute a new tradition where members of the
community can make proposals which the community votes on.

Advantages: decisions can be made.
Disadvantages: decisions can be made.

The required majority for the adoption of proposals can be simple or
qualified. Even if the qualified majority is 3/4, this would be better
than the veto system we have today. Although a veto can be overridden
by a 3/4 majority, as far as I know, this has never happened in the
past.  Today someone voting -1 means end of discussion. 

I dare anyone to -1 that. Regards, Ceki


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]

[Chris Duprat]

Hello,
Each structure has a cost depending on his level of organization. I think
there is today to many project in the jakarta and the xml project. I feel
confuse about finding the right information at the right place. And I think
it's high time to merge xml and jakarta.
The way java is organizing code in package is rather simple and efficient,
maybe organizing project this way is the solution.
We should debate about this organization.
I propose some package organization :

XML(Xerces,Crimson)
XSL(Xalan,FOP)
SVG(Batik)
WebApps(Cocoon, JetSpeed...)
JSP (TagLibs)
FrameWork(Turbine, Avalon, Struts..)
Project Management (Ant, Slide)
Metric & Testing (Log4J, WatchDog)
ToolBox(ORO, RegExp, Lucene)
...
I'd like your opinion about it, which package with which existing project.

Ciao
Chris
-
agitateur depuis toujours
***


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: On unity and coherence [was Re: [Request For Comment] POI @ apache]

[Paulo Gaspar]

This is obvious from the "jakarta-commons" growing activity. More when you
compare it with "xml-commons".


Have fun,
Paulo

> -Original Message-
> From: Sam Ruby [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 05, 2002 7:35 PM
>
> ...
>
> My feeling is that communities need a critical mass, as do
> meta-communities.  I'm not sure what that size is, but in my mind the XML
> project has not reached it.  And it is not just size that is the issue, it
> is the presence (or lack) of people who cross pollinate ideas.  Within
> Jakarta, this is being done on an ever increasing scale.
>
> ...
>
> - Sam Ruby


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]

[Micael Padraig Og mac Grene]

At 10:40 AM 1/5/02 -0500, you wrote:
>I would also like to personally commend Jon with his efforts to better
>document Jakarta. He has put a lot into the Web site (probably 90%), and
>we all owe him a great debt.
>
>-Ted.


Despite Jon's "candid remarks," as you put it, Ted, I too would like him to 
know that I join a throng in saying thanks.

- Micael


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]

[Sam Ruby]

Stefano Mazzocchi wrote:
>
> In my mind, all this long trail of thoughs yields the following
> equation:
>
> metacommunity size * community coherence * individual freedom =
> constant
>
> in result, if we unify the two projects, we double the size of the
> metacommunity and we must pay the price of decreased coherence and/or
> decreased individual freedom.

So, if we half the community size we double the coherence and/or individual
freedom?  What happens if we half it again?

Hmmm.  I guess the "optimum" community size is "1".

Reductio ad Absurdum

I think this equation misses the important second order affects of
collaboration.

My feeling is that communities need a critical mass, as do
meta-communities.  I'm not sure what that size is, but in my mind the XML
project has not reached it.  And it is not just size that is the issue, it
is the presence (or lack) of people who cross pollinate ideas.  Within
Jakarta, this is being done on an ever increasing scale.

Perhaps a metric that would be more useful is to contemplate the size of
the intersection between the subscribers to any two mailing lists picked at
random.  Without looking, it is clear to me that however you choose to
quantify this metric, Jakarta would greatly exceed XML.

What you have observed lately has been a spike of activity on the general
mailing list.  One thread dealt with the ever popular coding style issues
(which unfortunately overwhelmed the more important underlying issue that
Jon was trying to get us to face).  The other thread dealt with the
intentionally high threshold that we have for accepting new Jakarta
projects.

Now for a thought experiment: if POI were added to Jakarta, would this
metric overall increase or decrease for Jakarta?  If POI were added to XML,
would the metric overall increase or decrease?

Ignoring the fact that the following are clearly related, which is more
important: community coherence or mission coherence?

- Sam Ruby


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]

[Ted Husted]

About a year ago, the PMC co-opted the General list for it ongoing
meetings. Since then, it's been used for both general interest
discussions, like what's up with Linus or Microsoft, along with the
general business of running Jakarta. 

It's possible that we may need to create a discussion list for the
off-topic threads, since as you point out, the list is required (for PMC
members at least).

Personally, with the exception of Jon's candid remarks, I think the
noise-to-signal ratio is relatively low. I recognize the amount of work
Jon does around here, and, personally, I forgive him those. (Though we
may need to put the link to Jon's self-deprecating page <
http://jakarta.apache.org/site/jon.html > on the footer of the General
mails ;-)

There is a distinct need for better, more easily maintained
documentation, so that the things we do decide don't get buried on the
list. I tried to use the Jyve FAQ for a time, but there were reliability
problems, and the URLs are long 

http://nagoya.apache.org:8080/jyve-faq/Turbine/screen/DisplayTopics/action/SetAll/project_id/2/faq_id/38

At this point, I'm reconciled to do more work on the Jakata site using
XML in the old-fashioned way. 

We have some unratified guidelines that expand on the ones (you?)
originally set down. 

http://jakarta.apache.org/site/proposal.html

If you were able to review them, I would of course very much like to
have your comments before making a final update and calling for a vote. 

I would also like to add more rationale for some of the guidelines. The
recent dicussion regarding coding conventions had less to do with the
conventions themselves, and more to do with why we even have
conventions. (And having conventions, why don't we enforce them.) 

As Jakarta grows, it becomes more and more important that we have better
ways to introduce peoole into the fold. Right now, there is a tendency
to make someone a Committer and let them find their own way around. At
this time, I'd like to go to work on a Committer's guidebook that would
help explain how things are done (starting with How to do a Release --
which raised the JAR discussion the other day). 

I think the real solution to improving the noise:signal ratio is to move
away from the "oral (email)" tradition we have now, and move back toward
providing more grassroots documentation, as you did in the "preamble" to
the original constition. 

http://java.apache.org/main/constitution.html

An actual history of Jakarta might also be useful to give people a
better perspective. Here's one passages I tucked away (to be joined by
your own snippets of late).

Pier to Jon - Thu, 21 Dec 2000
> We've traveled a long
> way together, from my very first steps in open-source land in January 1998,
> to our marvelous meeting at the first ApacheCON in October 1998, the Jakarta
> room meeting, all JavaONEs, and all we did together to bring this project
> where it is right now.

Pier again, same day 
> And we, as the newly formed Apache Software Foundation, accepted that code
> in donation as a point of start for the Jakarta Project. I was there, in
> that meeting room, that day when we outlined how the process would have
> evolved, with Jon, Stefano and Brian. And I was there, on stage at JavaONE,
> when Patricia Sueltz announced the spinoff of the project againg with Jon,
> Stefano and Brian. If that has been a wrong decision, we four are the people
> to blame...

A coherent history might help with many of the questions about why we do
things the way we do. (Or why we don't do some things at all.) I think
clearly documenting the Apache Way would be an important first step to
unifying the Apache Projects.

I would also like to personally commend Jon with his efforts to better
document Jakarta. He has put a lot into the Web site (probably 90%), and
we all owe him a great debt. 

-Ted.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

On unity and coherence [was Re: [Request For Comment] POI @ apache]

[Stefano Mazzocchi]

Jon Scott Stevens wrote:
> 
> on 1/4/02 4:14 PM, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
> 
> > That makes me wonder about the real causes of this "whole fucking mess"
> > and "jakarta is fucked up today" feelings of yours...
> 
> Of course. I forgot. I'm always wrong. Sorry.

I wasn't thinking about you, but about the fact that there might be a
limit about amount of the amount of traffic (or subscribers) a mail list
can handle without automatically ignite friction because of
misunderstanding that are generated by degradation of signal/noise
ratio.

Usenet is the perfect example of this.

As much as I would love to avoid project containers, I fear the
degradation of signal over noise in the required '[EMAIL PROTECTED]'
mail list.

The [EMAIL PROTECTED] mail list, for example, is a very low traffic
mail list and even politically harsh discussions (see the recent ebXML
vs. UDDI feelings, a very bad battleground for corporate interests!) are
quickly resolved.

At the same time, collaboration between subprojects is much less
required, mostly because 'contracts' are established someplace else
(W3C, JCP) or don't need many changes that couple of GUMP nags and Sam
emails can't fix.

But at the same time, this lack of collaboration and subproject
isolation prevents (or has prevented in the past) coherence in the
infrastructure, reduction of overlap between projects and unity at the
direction level that resulted in the major Xerces vs. Crimson fight.

Yes, Jon, your attitude has changed a lot from that very first email to
me (the first reply I ever received from an open source mail list!) 4
years ago where you told me (publicly!) that you once visited Florence
in Italy and you had a great time. While new-httpd@ was putting down
people daily, your message made me feel between friends.

I know this has also something to do with your RSI hand problems (oh,
BTW, I got an Aeron chair as well :) and I feel terribly lucky and
terribly sad because were you and Brian that taught me everything I know
about OSS community engineering. I seems so long ago :/

Now that I know those individuals at new-httpd@ that had such a bad
reputation and I have witnessed with my eyes the changes in your
attitude, I think this has very little to do with the person attitude
but something to do with 'size', frequency of messages and the relative
frustration of impersonal communication (probably some exhaustion as
well, I've been one entire year out of this and I think I learned many
things from that).

Anyway, besides the POI, this thread makes me wonder a lot: on one hand,
we have the clear potential of mixing together jakarta+xml and showing
the ASF a way to 'flat' the hierarchy of efforts, bringing more vibility
to the communities. On the other hand, the intrinsic degradation of
performance due to the increased overlap and required rules has the
potential to waste all the benefits of such a flat hierarchy.

Imagine the kind of discussion that would emerge on an eventual
"[EMAIL PROTECTED]" about standardizing an apache-wide DTD for
documentation. Scary, eh?

There is something else that makes me wonder: the first important thing
about OSS that I learned is that, given the same ideas and direction, a
buggy software makes a better open community than non-buggy one. Code
stability and polishness must come, but after a community is already
established.

Could it be possible that lack of coherence could do the same as
software bugs for metacommunities (communities about communities, such
as all the general@ mail lists)?

I mean: a common and strong philosophical foundation must exist in order
for such metacommunity to remain stable, no question about this, but
there could be a point of equilibrium to the coherence that can achieve
between its internal communities without deteriorating other issues
(such as collaboration).

Sourceforge seems to show that lack of metacommunities is a way to allow
scalability of efforts, at the cost of unity, direction and coherence.

Perl, Python and the old Apache Group seem to suggest that
metacommunities that range from one to a few people, give strong
direction, sacrificing scalability of efforts. 

Linux and GNU have metacommunities of single individuals (Linus and RMS
respectively) and seem to scale incredibly well, but sacrifice choice
(in OS architecture, for the first, on software licensing on the
second).

Jakarta and XML.apache are the biggest metacommunities around. And I
think it shows: on all the other ASF projects, a few codebases are
contained, this results in a metacommmunity coincident with the
development community.

In my mind, all this long trail of thoughs yields the following
equation:

 metacommunity size * community coherence * individual freedom =
constant

in result, if we unify the two projects, we double the size of the
metacommunity and we must pay the price of decreased coherence and/or
decreased individual freedom.

But are we sure the pros outweight the cons?

-- 
Stefano Ma