Re: [sendpage-devel] SoC Status Report for Week 1+

[Zak B. E. <za...@sp...>]

Hi again! =)

On 6/16/06, Kees Cook <sen...@ou...> wrote:
> You should be able to check out an "anonymous" copy of the CVS tree.
> >From that, you can generate "cvs diff -up" output, and also merge in
> changes as new stuff is added upstream ("cvs update").  This may be more
> flexible than using the RCS method.

That's what I did first actually; grab a working copy from anoncvs, then
read and make changes in it.  It just so happened that my preferred
editor also had the convenience of being able to store working copies to
to version control systems simultaneously, so I can make incremental
changes with log notes on each change.

> There was a goal to move to using "Device", so that "Modem" and
> "TCPModem" could be abstracted.  (For example, there are some Paging
> Centrals that have their serial ports attached to network console
> servers, which can only be reached over the network (instead of via a
> serial line).

Ah!  So that's why!  I'll note that then :)

> >   - The Perl `metagoofs' of _not_ using the `warnings' and `strict'
> >     pragmas as appropriate are evident in all modules of the code.
> >     [...]
>
> I couldn't agree more.  :)  There will likely be a lot of clean-up
> needed to solve this.  It would be a major improvement, though.

Much of my latest changes has been on getting the existing variables
properly localized, removing spurious variables (or at least commenting
them out) and revising oft-used constructs to their clearer Perl
equivalents (i.e. if(!defined(foo)) becomes unless(defined(foo)) or even
unless(foo).)  This is the first pass; the next would be to plow through
the algorithms themselves and simplify them.

> Serial devices need to be locked in a very specific way ("uucp-style"
> IIRC) to in-operate correctly with other programs that want to use those
> devices.

Yeah, I isolated the locking code in a test program a while ago and
found its usefulness; indeed Perl's flock() mechanism isn't strong
enough to ram up with pppd and friends :P Still, I think we could put in
some flock() magic in the locking code to avoid some redundancy when
multiple calls to lock are performed (AIUIC a nonblocking flock() would
stop locks sooner, or at least allow us to have some better `while you
wait' code up...)

> >   - Last (but not the least) is perhaps the main object of the
> >     enhancements project: making the object configuration code
> >     simpler and easier to understand.  From my reading, it seems
> >     [...]
>
> This is true (even in Modem.pm).  I was thinking about the device itself
> (from a locking perspective), and then later about the connection
> through the device (baud rate, parity, etc).  Since the connection
> parameters can change, that's why there is a separate "init" function.

I see; yeah, both the new() and init() methods make sense here.  Anyhow
a Modem or Device can re-init() itself, or can be re-init()-ed by the
user.

> I'd like to make the follow suggestion for a common "style", which is
> what I currently use.  (There's not need to change old code's style
> unless you really want to.)

Actually this is the style I'm using right now (enforced by CPerl-mode's
styles-alist.)

> That's fine by me.  Once you've got a collection of patches ready, I can
> cut a branch and get it started in the CVS tree for you to follow.

Great! =) I hope to be able to get my first set done by next week, along
with the draft of the specs document.

> > now work on proceeding with formulating a coherent design
> > specification for improving Sendpage and its associated modules (I
> > personally feel that the sendpage program itself it quite big, and
> > that seems to be an indication for further redesign.)  Also, since I
>
> Agreed.  There are elements that I'd love to see pushed out into
> separate CPAN modules (names the badly-named "KeesConf" -- should be
> "IniConf" or "FallbackConfig" or something, and the SNPP server -- which
> was actually PUT in CPAN by someone else, based on the Sendpage SNPP
> class).

Erm, `KeesConf' is badly-named?  I'd rather think otherwise, but yeah,
it should be something that describes itself neatly.

> Zakame, sorry I took so long replying to this!  I should be quick to
> respond from now on.  :)

Hehe, no problem =) Truth is I've been away too for some schoolwork, but
now I think there isn't much at the way for me to focus on the
project. =)

Cheers,

Zakame

-- 
Zak B. Elep  ||  http://zakame.spunge.org
za...@ub...  ||  za...@sp...
1486 7957 454D E529 E4F1  F75E 5787 B1FD FA53 851D