[Tutor] Turning a "script" into an "application"

[Bill Mill]

> >I believe that sockets would be simpler for him to use, and that he
> >doesn't need all of the protocol worry that you mentioned earlier,
> >because he can simply pass a fixed-length message from the controller
> >to the network script. Reading the socket is very simple; if there is
> >data, read X bytes. If not, keep on chugging.
> 
> I'm skeptical of this. But I admit I haven't written any applications this
> way. There will at least be buffering issues with the input - a complete
> command may not be available at once. It is possible that he will
> eventually want a threaded server anyway - one thread to listen for
> commands and another for the actual sniffer. In general I try to avoid
> inventing communications protocols from scratch. And Python xmlrpc is very
> easy to set up.
> 

It may be that xmlrpc is easy to set up and easy to use; I've never
used it. I'll look into it.

As for my bias towards socket development, I will readily admit to
that. I've spent a fair amount of time impelementing protocols, while
I've never written anything other than toy threaded applications, so
my view is certainly biased. I just feel that a simple socket protocol
is very easy to implement, and avoids queues, locks, and other less
familiar (for me) threading concepts.

I'm not yet ready to concede my position, so I'll make one final
arguments for my position, and it's a higher level one. Conceptually,
the library and the GUI are different applications in this case. It is
entirely possible that this network code he's written will be useful
to others as a library. As such, it makes more sense conceptually to
keep it separate from the front end.

While a threaded approach doesn't necessarily preclude conceptual
seperation of the front end from the back end (can I use more jargon
than that?), it implies more similarity than they perhaps actually
share. I question the necessity of shared memory, but if it's more
comfortable for him, then by all means, he should go with it. Either
way, he needs to be prepared to handle a separate set of issues.

I'm glad we could have such civilized discourse on the topic; I'd like
to point out here that this list has been excellent in the short time
I've been reading it. I think it's good that we're exposing the pros
and cons of each approach.

Peace
Bill Mill
bill.mill at gmail.com