>Ok. Strict and precise mode on. I usually prefer friendly discussions 
>that lead to a consensus, but let's adapt to the POI way.
>

Perhaps your not aware of it.  Your tone doesn't come off that way.

>These are my thoughts and opinions. People can travel the thread at will 
>in the archives. Thanks anyway for the pointer to the full thread, where 
>people can see that POI integration is very welcomed, but also that I'm 
>not the only one to have these fears about so much code.
>

Please take a closer look at the classes.  "so much code" is referring to
the number of classes.  If you'll look closely you'll see that there is very
little code there.  Its just very well encapsulated.  I had the same
reaction to the implementation when I first saw it.  I grew to appreciate
it's simplicity and the sheer LACK of code needed to implement things within
it.


>Big words. Nothing is written in stone, and all projects evolve over 
>time. Accepting evolution means the project can adapt to the community 
>feedback and go beyond the expectations or thoughts of its originators.
>

true.  I'm giving my feedback.

>Look at what happened to Cocoon : it started as a small servlet written 
>by Stefano to build Apache web sites and it is now a major player in its 
>area. This is because it accepted evolutions and revolutions.
>

POI started out as Excel only.  

>I can't believe you really think Cocoon is the only tool out there where 
>XML<->POI integration could be useful. Or is because this serializer has 
>always been presented as a Cocoon component ?
>

Are you volunteering to spawn a project around non-cocoon uses for XML-POI? 
Most of my XML work is centered around Cocoon.  I'm ill-qualified to
implement these ideas for you.

>Look back to 
>http://www.mail-archive.com/[email protected]/msg00079.html : 
>XML_DBMS, Oracle XSU and XSQL. No mention of Cocoon.
>

I've seen those projects.  Are you volunteering to start a project on that
level?  Such exceeds me.  You seem to have some ideas that are more
expansive than what the creators of this software had in mind.  Are you
volunteering?

>As I said in this thread "XML is now a dominant technology in the 
>software arena, because it moves software development from sequential 
>logic to data transformation. And reading/writing legacy formats *is* 
>data transformation." You can't ignore XML, or POI will stay a small 
>project for people having in-depth knowledge of legacy data structures.
>

I disagree.  POI has attracted a number of very talented developers in a
pretty short period of time who were able to come up to speed on the skills
required and work in their area of interest.  A number of users have been
attracted as well.  Please research the POI project further before making
these assertions.  

>Granted, I looked deeper at it because of the lots of files that went 
>down through cvs update. But this doesn't change the problem.
>

There was a message that cross referenced what was proposed quite in depth
with prior existing classes as well.

>We're talking here about a 10-classes framework. The purpose of moving 
>it out of both POI and Cocoon is not to create a fully-fledged Apache 
>project, but to allow other projects to use it as well without depending 
>neither on POI nor on Cocoon. The community will start around the HSSF 
>serializer and grow when other projects implement new serializers.
>

even a small project requires some semblence of a community to justify the
added complexity of seperating it from larger project do you not agree?

For intellectual debate, what if POIFS was moved into Jakarta commons?  It
would increase the difficulty of installing POI, make it harder to find and
more.  Do the costs of this justify any benefits?  

>>Are you volunteering to spearhead this community?
>>
>No need for a charismatic leader (see above), which I do not pretend to be.
>

I see.  I'm not sure this really makes these particularly accessible to
other projects unless someone is volunteering to evangelize their use.  We
could just bury them deep underground to achieve the same effect.  Unless we
have a volunteer.  I personally do not have the time at the moment to do
this.

>XML is a very general-purpose technology, and the arena a document 
>belongs to is defined by its semantics. As far as I can say, Gnumeric 
>DTD is more in the spreadsheed arena than Cocoon's one, which is 
>DTD-agnostic (handles _any_ DTD).

I missed the point in the above paragraph.

>Ok. I was overworked when the vote was taken back in January and didn't 
>look deeper at it. But once again, the usual integration code for a 
>third-party tool is a few small classes. That's why I didn't investigate 
>further, just as, I think, many Cocoon committers.
>

I see.  I'm pretty overworked right now.  I know how it feels to be
overworked.  I've only seen messages from 3 cocoon committers.

>Will people blame you and say you're a liar if this is good for the 
>health and spread of the project ? I'm sure of the contrary.
>

*shrugs* Are you quoting Machiavelli?

>>Does that answer your question?
>>
>I'm starting to wonder about the future of POI if you refuse to consider 
>XML as a general-purpose technology, just as a java compiler.
>

java compiler?  Huh?

the law of the hammer?  

*shrugs* so far the growth has been quite remarkable despite our not
becoming a "me too XML-enabled" project.  Its not to say that I do not hope
XML projects use POI, I just prefer to leave XML to the experts and that POI
focus on the very complex problem area of mapping the there over complicated
legacy file formats to APIs.  

Anyone in the POI community feel like thats not a big scope?  

Somewhat offtopic:
Oh and welcome to the POI community Sylvain.  I've enjoyed much of your work
on Cocoon.

Thanks,

Andy

Reply via email to