Re: Jakarta Status [was Code conventions]

[Stefano Mazzocchi]

Jon Scott Stevens wrote:
> 
> on 1/4/02 4:20 PM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> 
> > They aren't even comparable, are they?
>
> Of course not.

No, I agree, I was just teasing :)
 
> http://jakarta.apache.org/velocity/dvsl/
> 
> When DVSL is integrated into Turbine's presentation layer and people are
> using it, the comparison will definitely be Cocoon2 vs. Turbine.

Uh, cool, let me take a look...

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




--
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

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: 

RE: [Request For Comment] POI @ apache

[Paulo Gaspar]

IMO Andrew puts the finger on why POI is only used on a server.

One of my 2 interests (the other is indexing) on POI is exactly the 
typical one he describes:
 - I want to be able build Word and Excel documents on a Web Server 
   without going back to use MS IIS and COM automation.

(... even because using COM to control Word/Excel in a multithreaded
application sounds VERY problematic and all the other methods I can
think of are some other kind of PITA.)


Hey, for a client application, I would use Delphi or VB + COM in 
Windows and something around OpenOffice in Linux. 

Hey! I am just finding out how much server side POI really is!!!


Have fun,
Paulo Gaspar

> -Original Message-
> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 05, 2002 3:07 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [Request For Comment] POI @ apache
> 
> 
> Hi Pete,
> 
> 
> >> Me to. POI doesn't seem to have anything to do with XML and FOP is 
> >> essentially a renderer for a XML dialect right ?
>  
> > POI are codecs for reading different office formats in java. Sounds
> much more 
> 
> correction:  reading and writing (I don't bother with simple "readers",
> there are a hundred of those out there).  (not to be pedantic just to
> distinguish the purpose)
> 
> >suited to jakarta than xml ... but even then it does seem to be out of
> scope 
> >- what the hell has it got to do with serverside technologies ? But
> then 
> >again I have no problem with this ;) 
> 
> Well POI is pretty much strictly used on serverside projects.  I've yet
> to hear from a user who is currently using this in a clientside
> application.  
> 
> A typical scenario for POI's HSSF (the Excel API), for instance, would
> be for instance that you have a web application that provides a
> financial report in HTML.  Well the accounting department insists on
> having it in Excel format.  You have a few good and bad solutions, but
> POI's HSSF API (codec if you prefer) will allow you to serve the XLS
> file from your Unix server running Tomcat for instance.  You could of
> course have the opposite scenario (the accounting department uploading
> the XLS) and HSSF can help with that too.  Either way POI has NO GUI. 
> It could be used of course in a client app if you wanted, but Tomcat is
> being used by Netbeans for something or the other so go figure on what
> is strictly serverside so to speak.  
> 
> Hope that clears things up  (and I hope it doesn't make you doubt that
> Tomcat is a serverside component ;-p).
> 
> -Andy
> 
> 
> >-- 
> >Cheers,
> 
> >Pete
> 
> 
> 
> -- 
> 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: 
> 

--
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]

[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: Code conventions

[Gunnar Rønning]

* "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:
|
| It could even happen in the USA and it is quite dangerous to think
| otherwise (because then you are not alert).

Well, I would argue that it is happening in the US now with the new 
military courts. 

-- 
Gunnar Rønning - [EMAIL PROTECTED]
Senior Consultant, Polygnosis AS, http://www.polygnosis.com/

--
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: [Request For Comment] POI @ apache

[Andrew C. Oliver]

Hi Paulo,


>IMO Andrew puts the finger on why POI is only used on a server.
>

good!

>One of my 2 interests (the other is indexing) 
>on POI is exactly the 
>typical one he describes:
> - I want to be able build Word and Excel documents on a Web Server 
>   without going back to use MS IIS and COM automation.
>
>(... even because using COM to control Word/Excel in a multithreaded
>application sounds VERY problematic and all the other methods I can
>think of are some other kind of PITA.)
>

You got it exactly.  Feel free to join us on the poi-devel or
poi-general-users lists (http://poi.sourceforge.net).  Apparently many
people share your interest:  The POI project climbed to #4 on the charts
today.

>
>Hey, for a client application, I would use Delphi or VB + COM in 
>Windows and something around OpenOffice in Linux. 
>

Complete agreement.  For a client app where you know what your client is
(and with an office doc you probably know who your client is), there
would be little reason to use POI (other than the office automation API
in VB is kind of a pain to use because its based on programmaticly
simulating the user which can be painful).  I'm not sure there would be
a reason to use Java (most things could probably be done as a big fat
Excel macro for instance).

>Hey! I am just finding out how much server side POI really is!!!
>

Glad that shined the light.  


>
>Have fun,

Definitely!

>Paulo Gaspar

Thanks!

-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]

[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]

[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]

[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]

[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ü]

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]

[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]

[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]

[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: More abuse of coding styles...

[Steve Downey]

Your javac has a configuration setting for the class names of inner classes?
Although the inner classes use a $ embedded, rather than as a lead
character. It's a similar issue.

The recommendation in C that _ is reserved for the implementor is not a
linker issue, but more of a namespace scoping issue. There isn't a good way
of marking a function as to be used by the implementor or the compiler, in
such a way that a programmer can not conflict with it. Java has private
which accomplishes that. 

But reserving some characters for the implementors is not really a bad
thing.

> -Original Message-
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 04, 2002 8:15 PM
> To: Jakarta General List
> Subject: Re: More abuse of coding styles...
> 
> 
> On Sat, 5 Jan 2002 03:19, Steve Downey wrote:
> > > 
> 
> > >
> > > | "Variable names should not start with underscore _ or 
> dollar sign $
> > > | characters, even though both are allowed."
> > >
> > > The _instanceVariable and also the __staticVariable idea
> > > makes real good
> > > sense to me nowadays. Do you have any arguments against it?
> > > (btw; this is
> > > a genuine question!)..
> >
> > Because those characters are used by implementors and code 
> generators.
> 
> all java code generators I use have configurable settings.
> 
> > They
> > are legal, but not intended to be used by programmers.
> 
> Not relevent for java. In C this may be so but that mainly 
> had to do with how 
> the linker mangled names. And this was more separated out 
> between system-user 
> code
> 
> -- 
> Cheers,
> 
> Pete
> 
> 
> Sorry, I forgot to take my medication today.
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

--
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:   
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]

[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]

[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?  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 w

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]

[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]

[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]

[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: More abuse of coding styles...

[Peter Donald]

On Sun, 6 Jan 2002 11:26, Steve Downey wrote:
> Your javac has a configuration setting for the class names of inner
> classes? Although the inner classes use a $ embedded, rather than as a lead
> character. It's a similar issue.

And whats that got to do with the price of fish? $ is not valid in 
identifiers in java language (but fine in .class file format).

> The recommendation in C that _ is reserved for the implementor is not a
> linker issue, but more of a namespace scoping issue.

errr  go have a look at the evolution of c/linkers and the pains some 
people went through re different linker/header file combos.

> There isn't a good way
> of marking a function as to be used by the implementor or the compiler, in
> such a way that a programmer can not conflict with it. Java has private
> which accomplishes that.

private is an access marker - it does not define any metatype. Java has a 
crap metadata infrastructure - thats one of the things that C# did far better 
than java. Its a feature people have been asking for since 1.0 days but sun 
keeps dropping the ball or implementing workarounds.

> But reserving some characters for the implementors is not really a bad
> thing.

Sure it is - it makes it acceptable for them to write poor code.

-- 
Cheers,

Pete

"The perfect way is only difficult for those who pick and choose.  Do not
like, do not dislike; all will then be clear.  Make a hairbreadth
difference and heaven and earth are set apart; if you want the truth to
stand clear before you, never be for or against." - Bruce Lee

--
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]

[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: More abuse of coding styles...

[Steve Downey]

> -Original Message-
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 05, 2002 9:53 PM
> To: Jakarta General List
> Subject: Re: More abuse of coding styles...
> 
> 
> On Sun, 6 Jan 2002 11:26, Steve Downey wrote:
> > Your javac has a configuration setting for the class names of inner
> > classes? Although the inner classes use a $ embedded, 
> rather than as a lead
> > character. It's a similar issue.
> 
> And whats that got to do with the price of fish? $ is not valid in 
> identifiers in java language (but fine in .class file format).
> 

$ is a perfectly fine character in a java identifier. Even as the initial
character. That's why it's specifically mentioned in the sun coding style
guide. It's legal, but not meant for use by all. 
IOW:
class $ {
  public int $() {
int $ = 5;
return $;
  }

  static public void main(String args[]) {
$ dollar = new $();
System.out.println(dollar.$());
  }
}

is legal. Ugly as hell. But legal.

> > The recommendation in C that _ is reserved for the 
> implementor is not a
> > linker issue, but more of a namespace scoping issue.
> 
> errr  go have a look at the evolution of c/linkers and 
> the pains some 
> people went through re different linker/header file combos.

Been there, done that, have burn marks. The identifier name space starting
with _ is reserved for implementors to provide such things as library
functions with external linkage, used by the rest of the library, without
running into conflicts with user declarations. The compiler is even entitled
to emit calls to these functions, or reference these variables, without your
direction. So if you name variables or functions things like _alloc, or
_err, and your program crashes and burns, you've got no one to blame but
yourself.

> 
> > There isn't a good way
> > of marking a function as to be used by the implementor or 
> the compiler, in
> > such a way that a programmer can not conflict with it. Java 
> has private
> > which accomplishes that.
> 
> private is an access marker - it does not define any 
> metatype. Java has a 
> crap metadata infrastructure - thats one of the things that 
> C# did far better 
> than java. Its a feature people have been asking for since 
> 1.0 days but sun 
> keeps dropping the ball or implementing workarounds.
> 
> > But reserving some characters for the implementors is not 
> really a bad
> > thing.
> 
> Sure it is - it makes it acceptable for them to write poor code.
> 

In what way does it make it acceptable for them to write poor code? For
example, the JSP spec reserves _jsp, jsp, _jspx and jspx for identifiers
used in the classes generated by the page compiler. What other way do you
propose to guarantee that the compiler won't generate names that conflict
with ones I declare in a page?


-SMD
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

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

Re: More abuse of coding styles...

[Geir Magnusson Jr.]

On 1/5/02 11:22 PM, "Steve Downey" <[EMAIL PROTECTED]> wrote:
> 
> In what way does it make it acceptable for them to write poor code? For
> example, the JSP spec reserves _jsp, jsp, _jspx and jspx for identifiers
> used in the classes generated by the page compiler. What other way do you
> propose to guarantee that the compiler won't generate names that conflict
> with ones I declare in a page?
> 
> 

As a SWAG, I would think you could parse out the ones you declare, keep a
list, and ensure you don't generate anything that conflicts?

-- 
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: 

Cultural homogeneity

[Geir Magnusson Jr.]

I was leafing through my copy of "A Pattern Language" by Alexander, Ishikawa
and Silverstein, which is really about architecture of human habitat
(buildings and environs), and ran across some interesting assertions about
society and groups.

I haven't read the book end to end, as I just pick it up and read bits and
pieces, but I am generally struck by the validity of the basic insights
expressed.

I thought I would share, as my thinking about removing community containers
here in Jakarta, XML et al resonates well this.  There is nothing which says
the following is any more valid than any other point of view expressed here,
so this shouldn't be read as an appeal to some kind of 'authority' (like we
*never* do that here...)  - just interesting as it comes from another
intellectual discipline studying the exact problems we are trying to grapple
with.

The summary for me is that I think that the Apache sub communities are
valuable, and should be kept.



"The homogeneous and undifferentiated character of modern cities kills all
varieties of life styles and arrests the growth of individual character."
(p43)

Kind of general as the assertion, the text then talks about three kinds of
structure, heterogeneous (bland and conformist),  ghetto (organized by
economic or physical characteristics, traps and isolates groups), and mosaic
of subcultures, the latter being the preference, with the conclusion :

"Do everything possible to enrich the cultures and subcultures of the city,
by breaking the city, as far as possible, into a vast mosaic of small and
different subcultures, each with it's own spatial territory, and each with
the power to create it's own distinct life style.  Make sure that the
subcultures are small enough so that each person has access to the full
variety of life styles in the subcultures near his own."

I think the notion of "power to create it's own distinct lifestyle" is the
important aspect that applies to the issue of disbanding the community
boundaries distinguishing XML and Jakarta.



"Individuals have no effective voice in any community of more than 5,000 -
10,000 persons" (p 71)

While I don't think that the quantitative values are important, I think the
fundamental idea is sound - in order for individual voices to be heard, the
group has to be small enough.  The conclusion :

"Decentralize city governments in a way that gives local control to
communities [...].  As nearly as possible, use natural geographic and
historical boundaries to mark those communities.  Give each community the
power to initiate, decide and execute the affairs that concern it closely."

I think I don't need to explain how this applies to us :)



There's more, but I'm beat.  Happy weekend. :)


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


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