Re: CVS Update: Barracuda

Hi,
Jacob Kjome wrote:

>
> I'd definitely encourage this.  We could even support multiple 
> scripting languages if need be...even in the same file, possibly.  
> Maybe using an XML format and declaring the scripting type on 
> different elements enclosing a particular scripting technique.  It 
> could be called  
> org.enhydra.barracuda.plankton.data.SriptingAssembler.  Could be 
> pretty cool and give users their choice of scripting languages rather 
> than forcing a single scripting language upon users.  The interpreters 
> could even be loaded using reflection so that there would be no 
> compile-time dependencies on these libraries so that the scripting 
> would be entirely optional.  We could always log the fact that a 
> scripting library isn't available and needs to be added to the 
> classpath in order to work if it doesn't exist.


I'm not for the xml-solution. We'd better go for some first-line 
descriptor, as xml already uses it and then support only one type of 
configuration in the body. The reason for this is very simlye: Otherwise 
we end up with overlapping syntactical requirements and need a 
complicated escape-mechanism like CDATA. E.g

o1 = Object1()
o2 = Object2()
if(o1.someAttribute < o2.someAttribute):
  #do something here

we would need to escape the <

Thats true for BSH either.

So the only thing to do would be to check the first line, if it contains 
a xml declarattion or some other descriptor like

#jython-assembler

and then instantiate the appropriate assembler.

If you really _need_ different config-formats. you should go for a 
MetaAssembler that includes several config files and dispatches accordingly.

Diez