lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@apache.org>
Subject Re: Proposal for Lucene / new component
Date Tue, 26 Feb 2002 13:08:56 GMT
On Tue, 2002-02-26 at 06:23, Manfred Schäfer wrote:
> Hi,
> 
> "Andrew C. Oliver" wrote:
> 
> >
> > I'm trying to learn enough about avalon to do this.  I'm having a hard
> > time of it.  After I read the conceptual documentation and see a couple
> > of code samples I'm like "now what?"  I need a "hello avalon" tutorial
> > to help me.. . U/f I can't write one (chicken and the egg kind of
> > thing).  I still am having trouble figuring out how to do something like
> > this via ant or even if ant is the right tool..  (I mean I love it for
> > builds but for this??) MAybe I have a mind block :-)
> 
> Ok. I have a few deficienies in my personality: I'm reading texts of other people mostly
superficial, writing mails to forums, bevor i'm really completed with thinking and some more,
which i will tell you later.
> Ant could be used for writing configurable indexing engines, but that smells little bit
like misuse of ant, you're right for that.
> I've also had a look at avalon last week: To me it seems like the standardization of
the meta pattern [interfaces, factories, proxies, managed objects, etc..]. Exactly the same
kind of coding, which shines through kelvins code. So avalon itself is merely a collection
of interfaces, Abstractfactories etc. It is surely a starting
> point for architectural considerations, but doesn't deliver anything more (kind of academical).
> 

Gotcha.  One day when I understand Avalon I'll be happy ;-) (see the
texts...see the code... can't connect the dots yet)

> Where do my thoughts differ from yours? I think of a more generic generation and transformation
framework (The cocoon framework is doing that (in a modified way)

 with the generation and transformation of html/xml via sax events.) The framework should
be useable for different kinds of generation and transformations (e.g. reading
> a database and writing the result as a xml-file). Therefore it needs a flowmap configuraton:
A sample configuration could be a JDBCDataSource followed by a dispatcher,


 which routes the data to the correct DocumentHandler on the basis of the data mimetype. The
DocumentHandler extracting the texts and giving them further to a
> consumer, which could be a lucene index.  I'm working on something, to make that more
clear, espacially a configuration file (dummy) and some Interfaces. I am not really

 sure, if this level of genericity is desirable. Over-genericity is one of the badest things
in programming. On the other hand, i don't think, that it isn't
> possible and it could be an adventure and fun. And maybe we could save us some refactoring
efforts. Although i agree with you, that iterative and incremental development

I'm not sure we disagree so much as I want a bit more of an iterative
development process.  "How do you swallow an elephant?"  "A little at a
time".  Not opposed to the ambition.  Perhaps if you patch the proposal
with modifications that make it more clear how achievable this is (in a
short period of time, we'll come together.

 is the best thing to do, i would encourage you to strive for a architectural metapher, that
will stand the times.
> 

I think there are some general pieces that we can develop early.  I
don't believe in writing architectural metaphors for a first go at
something.  Why?  Because your understandings are incomplete.  The
architectural Metaphor *IS* the incorrect one.  (I promise it is).  This
is even more true in an opensource project where new requirements and
people come in all the time.  So all I'm saying is lets scale this.. 
Start small.  Outline a vision for the *greater effort* and then for the
*smaller effort* and come back to a more elaborate system once we
identify problem areas in the first release.  

-Andy

> regards,
> 
> Manfred
> 
> 
> 
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
> 
-- 
http://www.superlinksoftware.com
http://jakarta.apache.org - port of Excel/Word/OLE 2 Compound Document 
                            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:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>


Mime
View raw message