Re: sockets

[Paul Kienzle]

On May 15, 2007, at 8:43 PM, John Swensen wrote:

> Paul Kienzle wrote:
> > On May 14, 2007, at 8:25 PM, Tom Holroyd wrote:
> >
> > > I finally added the sockets package to the octave-forge CVS (in 
> > > main/sockets).
> > >
> > > This allows only fairly rudimentary socket support at the moment.
> > > You can send byte strings back and forth.
> > >
> > > The testing code uses num2str and so on, and there are some routines 
> > > for serializing a matrix; the recent changes to int8() allowing 
> > > strings would make that even easier. Eventually it should be changed 
> > > to handle more types natively.
> >
> >
> > listen/send in sockets will conflict with listen/send in 
> > miscellaneous.
> >
> > I'm not sure if I'm the only one using it, but changing will mean 
> > user retraining.  I'll ask on octave-help.
> >
> > You may want to make send/recv reliable --- from my reading of the 
> > man pages the functions can stop before all the requested bytes are 
> > read.
> >
> > In general I prefer a higher level interfaces (e.g., Tcl) which hides 
> > the complexity of dealing with operating systems rather than a low 
> > level interface (e.g., Python).  This is especially bad when 
> > different operating systems provide different interfaces, and the 
> > scripting language blindly projects them into the scripts, making the 
> > developer test for specific systems in their code.
> >
> > - Paul
> I didn't realize there were existing methods for socket 
> communications.  After looking at them, they seem more like they 
> should have an "rpc_" prefix or something like that.  I made these 
> functions act as closely to the POSIX version of the functions as 
> possible.  I should extend them by making a socket_server and 
> socket_client in m-files on top of them, but still think the lower 
> level should be left intact for those with other needs.  I also plan 
> on modifying send/recv to handle different datatypes, including 
> structures.
>
> I can, however, easily put a "socket_" prefix on all the functions in 
> the socket package if you want me to.  Just let me know what the 
> consensus is.

Using the posix standard name for the posix standard interface is good, 
though replacing name and interface with something easy to use is best.

Splitting my listen.cc off from miscellaneous into its own separately 
installable package would be okay with me (e.g., merging it with 
soctcl), particularly if packages could identify naming conflicts on 
install.

I may eventually use the rpc_ prefix, though I would prefer to leave 
that to somebody with the time and inclination to implement a complete 
rpc package.

        - Paul