[DGD]1.1.53

[Felix A. Croes]

<sampsa at netsonic.fi> wrote:

>  Hello, I am having troubles with binary connections and the Dworkin's
> kernel library. I traced the problem back to connection.c where there is
> message() function:
>
> int message(string str)
> {
>     if .. 
>         return (send_message(str) == strlen(str));
>     ..
> }
>  
>  The document for vanilla DGD says: 
>
>  For binary connections, send_message() will return the lenght of the 
>  string if it could be sent right away, a number indicating how much of
>  the string could be sent initially ...
>  For telnet connections, send_message() will always return the length of
>  the string sent.
>
>
>  Network package:
>
>  The function will return 0 if there is room for more messages, and 1 if
>  not. ..
>
>
>  Which case this connection object is designed to serve?

Vanilla DGD.

Telnet connections are more flaky than they need to be.  I think I
will address this with an oncoming patch.


>  Also, the connection object totally lacks send_message(-1) capability
> used with network package.

The kernel lib doesn't really support the networking package at
all.  It supports the ichat version of DGD, which has functionality
which is similar to, but not quite the same as the networking
package.  It is up to the networking package to patch the kernel
lib.


>  How about if I set user object from port object, why is the login called
> before the connection call from port is finished. This way one cannot send
> any data without callout, because the message function is not functional
> until the connection is fully established and the thread
> started by connection() has returned the connection object. The open
> thread would be logical place for it.

Good point.  I'm changing this so open() always calls user->login()
if a user object is known, and set_user() only calls user->login()
if the current object is bound to a connection at the time of the
call.


>  I know some of these are network package specific problems, I think I
> still think bad support is sometimes worse than no support. I wish I could
> use the kernel lib as it comes and not have to make n modifications to it
> and notice you've changed the whole thing in next release: I would gladly
> use it unmodified if it were truly possible, it would give a stable base
> for development.

Which is indeed what the kernel lib intends to provide.  It is not
written with the networking package in mind, though.

Regards,
Dworkin

List config page:  http://list.imaginary.com/mailman/listinfo/dgd