if there's one central core of code to read and interpret the data, and
pass it along to the display layer, it shouldn't matter how many
different display layers you want to compile in/with, as if the format
of nocol should ever change there will only be one chunk of code that
needs changing and the rest will still work just fine. If you want to
base that on perl, C, or basic, doesn't make a difference to me.
On Thu, 3
Sep 1998, steve rader wrote:
> > From: "Jonathan A. Zdziarski"
> > The easiest way to do something like this would be to split the objects up
> > into two layers; the event layer which reads the events and reports them
> > to whatever higher layers request it, and the output layer which all of
> > which use the same event layer, and parse it/display it according to
> > however they like (through x, web, vt100, etc). This way you just have to
> > write a new display object and don't have to mess with the rest of the
> > code.
>
> Ahh, well, yea, I agree and I should have explained more:
> I envision doing all the *real* work in perl on the back-end
> via stdio ("event/report layer") and making the output all
> pretty in tcl/tk.
>
> steve
> -- -- -- --
> Steve Rader
> Systems & Network Manager
> WiscNet--Wisconsin's Internet Provider
> rader@wiscnet.net
>
Thank you,
Jonathan A. Zdziarski
Senior Systems Administrator
Netrail, Inc.
888.NET.RAIL x242
|