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:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
-- 
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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to