"Geir Magnusson Jr." <[EMAIL PROTECTED]> writes:
> I think that we really should consider this decision carefully. I
> really like having the options of using the Properties to load - since I
> would bet that the Properties class is very common for people to use in
> their own apps, every java101 programmer understands how to use it, etc,
> etc, etc
>
> The multi-key problem only surfaced recently with the multi-node
> template and jar paths, and that was solvable in the same way WM solved
> it, by letting the property be free form, and letting the entity that
> required multi-valued properties to parse in the way it needs.
>
> Everything that we want to do could be achieved with the
> java.util.Properties. If Configuration makes life easier internally to
> justify the added code, then I am all for it, but I still think that we
> should support the standard Properties object as a full functional
> method of init.
I'm with Geir on this one. I like the concept of sticking with a
regular Properties object, and letting the consumer of that properties
object tokenize as necessary. This presents a simple, friendly
interface while still being flexible enough to associate multiple
values with one key.
> > o UML Diagrams: Even if they are quick it would be nice to have. I
> > have asked a Turbiner (Ilkka Priha) if he could reverse engineer a
> > set of diagrams like he did for Turbine.
As I mentioned on the Turbine list, I'd like to Argo-ify whatever
Ilkka's commercial product generates.
--
Daniel Rall <[EMAIL PROTECTED]>
