Re: [Apso-devel] Logging system and defensive code (for Apso 0.3.0)

[Jeronimo Pellegrini]

On Sat, Apr 07, 2007 at 03:01:35PM -0300, Caio Marcelo wrote:
> Main reason is: today, both nettle and monotone are available in most
> Linux distributions (and also FreeBSD, at least Monotone).

I think Nettle also works on FreeBSD.

> For
> instance, creating
> apso packages for Debian will mean that we'll need to maintain also a 
> slogcxx package :-(

Ah, I see your pointi now.
So, the reasonable options seem to be:

1. Use another logging library
2. Include slogcxx in Apso

Maybe (2) is the best option right now...

> >One idea would be to not require a specific logging mechanism (or crypto
> >library, etc), so both these would work:
> 
> See that's not against the idea of abstracting logging functionality. We 
> have a LoggingEngine class, and a LoggingEngineSlogcxx that calls the bundled
> slogcxx.
> 
> Related question: did you drop the idea of using sanity.cc/hh ?

Er, no... It's in the roadmap (sanity checks a la Monotone)

> >- Scripting. Maybe Lua or Python would be interesting? Or some other
> >  language/tool? It would be nice if we could add more tests easily,
> >  like:
> >  + Write a description of the test (*)
> >  + Add the test name to a list of testa
> >  + Call "run tests" and all tests are performed.
> 
> I'll think about and try to come up with something. But what make me very
> unconfortable right now is that every apso command seems to NEED about
> 7 arguments, this isn't helpful at all. We need to come up with some 'trick'
> to make it smarter somehow.

Yes, I know... When I first wrote Apso, I wanted to first be able to
specify everything clearly on the command line, and later work on 
getting it "easier" to use.

> Monotone behaves smarter when you are in a working directory, for example.
> That --scratch directory is intended to be "killed" after every
> execution? If not,
> maybe making apso smarter like mtn, and suggest user to run apso from the
> scratch dir, and it will remember everything it can (will be stored in
> this directory).

Very good idea!

> What do you think?

I had originally thought that some wrapper script could be used on top
of it, but maybe it'd be better to use values from previous runs or
config files. Then the order would be:

1. Defaults
2. Values from previous run (if we are on a scratch dir)
2. Config file
3. Command-line

(each one overriding the previous)

I don't think we should implement the config file stuff right away; the
scratch dir idea seems more interesting.

> PS: Sorry for wearing the Usability-hat again... :)

No, you're right. It needs to be more user-friendly.

J.