[Cmake] RE: [Dart] cDart anybody?

[Ken Martin]

Hey Folk,

I think in general Dart is already a great piece of software and has
evolved quite nicely over the past couple years. There have been a few
rounds of feature improvements and each time Dart has become more
polished. I do have a wish list of features I'd like to see. I think
addressing any of these issues would be a nice improvement. But by the
same token Dart is working pretty well as it is right now.

1) The client should not require any extra software. It should support
being delivered as a binary. InstallShield etc... (sounds like this
could be done for windows already?, If so then that would be an easy
win)

2) On less common systems where a binary isn't provided, building it
should be fairly easy

3) The client should be firewall friendly (only use ports that are
commonly available, I think that is already the case)

4) Handle spaces / short paths / network paths / etc (this would be
nice, I tend to put most of my dashboards in directories with spaces
to test CMake, so this hits me more than most.)

5) The server should not need to have its memory limit specified

6) Processing a Dashboard should not require more memory than 2X the
size of its inputs (normally I would say this isn't an issue but in
relation to item 5 it becomes more of a problem, this may have been
fixed at one point I'm not sure)

7) It would be nice it the server did not need a checkout of the test
software to run

8) Smaller fonts

9) Disk space management (this is an important issue to me) Both the
client and server consume disk space until they run out. Some sort of
built-in disk space management would be great (this is for both the
client and the server) I'd like to be able to specify (let dart have
20 Gig for testing results and then start deleting/archiving/etc)


> I would like to propose this:
>
> 1. Write a real server in Java (or Python?)
>    - use XML-RPC as the connection layer (only... no more
> FTP/Perl hacks)
>    - don't require the server to have a checkout of the source code
>    - eliminate cron, have the server do the roll-ups,
> perhaps as results come in

Sounds good. I don't know Java or Python very well but so far I have
been concerned about Java's memory bloat (but I know neither language
well so ...)

> 2. Run with Jim Miller's re-factoring of the client
>    - Use Python with a class structure to allow better
> adaptation of new tools
>    - Python isn't the "cleanest" of languages eithor
>      Java would be my first choice, but distribution is a
> pain, i.e. no binaries, only JVM

I think binaries would be good, but I don't know the tradeoffs between
Java/Python so again take it with a grain of salt.

> 3. Rewrite the configuration files to be in XML
>    - using the tags, we can break out commands and
> arguments, no more guessing about spaces!
>    - much more flexibility than a "flat" file

I'm flexible on that one. I think we need to support backwards
compatibility but other than that whatever format is best.

Thanks for the good work
Ken