[Portland] Client library

[nf2]

Hi!


Lubos Lunak wrote:
>  Client library, i.e. the code apps will use.
>
>
> - I think the current C API with dapi_(read/write)(Command/Reply)Whatever is 
> fine as lowlevel calls and I find them directly reading/writing the wire 
> format to be fine as well, no need to complicate that. 
Do you mean directly reading and writing to and from the socket or into 
a "message container"?

The problem with directly writing/reading to/from the wire is that it 
might be blocking. I think for going async you might need an outgoing 
message queue like i just started to implement in "vio_trans".

The reason is to prevent the deadlock situation where both sides hang in 
a socket write() function. For instance the daemon wants to write a 
"Progress" message, but the client doesn't read from the socket, because 
it blocks in trying to write a "Cancel" message (and socket buffers are 
full).

> However C API for 
> apps/daemons should need improvements, I originally meant just a simple 
> processData( connection ) callbacks, but something like Norbert's callbacks 
> should be much better for use in apps. I'm however not sure I like the 
> implementation and I actually have some trouble reading it - things like the 
> layering of two tiny libraries make it IMHO needlessly complex. Might be I'm 
> just getting lost in it. 
Sorry, maybe i have to explain "vio_trans" a little more. You didn't see 
the async functions of vio-trans which is the main reason for the 
complex design.

It consists/will consist of three parts:

1) The VioTrans "Object" (in vio_trans.h):  Wraps around the socket. 
Carries one outgoing message and one incoming message which are being 
sent/recieved chunkwise.
Whenever select() indicates that a data-chunk can be written or read, 
vio_trans_write() or vio_trans_read() has to be called until a complete 
message has been sent/has arrived.
It has two state-models. One for the sending and one for the receiving part.

2) The VioTransAsync "Object" (in vio_trans_async.h) wraps around 
VioTrans to implement the outgoing message-queue and to fire a callback 
whenever a complete incoming message has arrived.

You have to call

vio_trans_async_write()

or

vio_trans_async_read()

whenever select() indicates that data chunks can be sent/read.

When the outgoing queue is almost full, vio_trans_async_enqueue(Message) 
will return a warning. This indication could be interpreted to slow down 
sending messages, to cancel a command etc,... Pretty tricky - and i have 
not finished/tested the async part yet.


3) Additionally there are the blocking functions 
vio_trans_blocking_sendMsg(), vio_trans_blocking_recvMsg(), which could 
be used in a simple synchronous API. They are defined in 
vio_trans_blocking.h

> If that spares me writing the C bindings I guess I 
> actually don't care as long as it works. I could then just do C++/Qt ones.
>   
Don't know. Perhaps my proposal with this async message handling might 
be an overkill and it would be better to begin with something 
straightforward like your implementation.
>  The library API should:
> - Allow synchronous calls of functions from the API
> - Allow asynchronous calls of functions from the API
> - Have callbacks for handling messages accepted while waiting for reply in 
> synchronous calls or when being idle
>
>  I wonder about thread safety and whether it'd be actually needed. A simple 
> solution might be a connection per thread, if something more powerful would 
> be needed there probably should be rather outgoing/incomming buffer per 
> thread and the library should merge and separate the data according to their 
> thread.
>
>   
Yes - regarding the client i reckon just stating that the implementation 
is not thread-safe and programmers should open one connection per thread 
(why not?) or care about thread-safety themselve should be ok...

Regarding the daemon: Instead of a truely async design - which would be 
quite complex - one could also discuss a completely different option: 
Running a daemon for every connection as child process of the 
application. A bit like a KIO-slave. Would be a lot easier with 
garbage-collecion,...

Norbert