[270] in BarnOwl Developers
Re: Release engineering, packaging and momentum
daemon@ATHENA.MIT.EDU (Alejandro R. Sedeno)
Thu Oct 29 18:04:21 2009
Resent-From: nelhage@mit.edu
Resent-To: barnowl-dev-mtg@charon.mit.edu
Date: Tue, 31 Oct 2006 16:59:39 -0500
From: "Alejandro R. Sedeno" <asedeno@MIT.EDU>
Reply-To: dirty-owl-hackers@MIT.EDU
To: dirty-owl-hackers@MIT.EDU
In-Reply-To: <tslzmbcs1rx.fsf@cz.mit.edu>
Sam Hartman wrote:
> Another problem I noticed is that some modules depend on other
> modules. In particular, jabber.pl seems to depend on colorutils for
> is_bold. I'm not entirely sure that's ideal.
That wouldn't be ideal, though I didn't find any references to is_bold (or
rather to 'bold') in jabber.pl. VT-asedeno.pl does depend on it, and this
was a choice I made in the context of me designing a conf system for my
use and that some friends might want to use. A more robust system will be
needed for code that I'd intend to widely distribute. Moving to a true
perl module-based system would certainly help and I look forward to seeing
this owlconf system move in that direction.
Any modules that implement protocol/network side code (e.g., jabber.pl)
should not depend on any style modules (e.g., ColorUtils.pl, VT-asedeno.pl).
Also, C code should not make references to any properties that externally
injected messages might have that are not standard (e.g., jabber.pl's
from_jid and to_jid). The perl code that generates owl messages should set
them up with sane values in default attributes so that owl will display
reasonably with no external knowledge. The only current violation of this
that I can think of is jabber logging, and I believe we all agree that
should be moved into perl and hooked generically back into C.
-Alejandro
