lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manfred Schäfer <mschae...@bouncy.com>
Subject Re: Proposal for Lucene / new component
Date Tue, 26 Feb 2002 11:23:41 GMT
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).

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 is the best
thing to do, i would encourage you to strive for a architectural metapher, that will stand
the times.

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>


Mime
View raw message