Re: [Cron-bug] Build environment

[Ryan M. Golbeck]

Jeff Bailey <address@hidden> writes:

> I generally work on the idea that libcron is the place where
> refactoring happens.  So, if we realize that something's been
> implemented in both at and cronttab, for instance, we would just
> migrate it as we saw fit.

Yeah, but there are some things I see right away as candidates here.
For example, crontab file parsing.  Used in both crontab and crond.

> I don't tend to plan too much in advance of coding.  I find that it
>tends to make me not program when I have the urge, so stuff that
>would've been done slower (due to poor design) doesn't get done at
>all.

Fair enough.  Feel free to start on whatever you want to work on the
most.  I think there a few of the higher level things we need to
decide on though so the pieces fit together.  ie.  how do we want
crontab to communicate to crond, dropping files somewhere or socket
communication.  And depending on his, how the information is organized
internally for passing between the two.  If all crontab does is check
syntatically and moves a file, then crontab really doesn't care about
internal formats.

> I like one function per file, because I don't have to generate tags
> lists.  When I'm looking for "add_entry()", I can expect to find it in
> "add_entry.c"
>
> I very rarely have static functions.  Most of the time, anything I
> would find worth seperating out, I would use in more than one place.

Alright, well we'll see what happens between our two styles then.  I'm
not sure I quite understand how you set your stuff up fully yet, but
I'm sure it won't be too long before I see what you mean.


-- 
Ryan Golbeck <address@hidden>
Computer Science
University Of Waterloo

GPG: 1024D/78916B84 
1B1B 2A87 3F00 A7FB 40F3  526D 36CF BA44 7891 6B84