[Kdenlive-devel] command end

[Rolf Dubitzky]

On Monday 25 November 2002 04:03 pm, Jason Wood wrote:
> I used non-blocking IO so that the renderer would continue working in the
> main loop even if no commands were available to be read. So for instance,
> once we have started a render, or playback the renderer would get on and do
> that, whilst still checking for new IO.
>
> With blocking IO and no threads, this doesn't work, because the renderer
> would pause everytime it checked for a command :-)
> So if you use blocking IO, you will have to use threads as soon as you
> implement any command that starts doing something, but may recieve other
> commands before it finishes. Things such as playback and rendering.

Sure, but the then you could still use select() or something, but idle looping 
with 100% CPU isn't the best thinf to do ;-)

> > Well, for now I just switched to
> > blocking IO, but we have to make sure that we know when a complete
> > command sequence has been send. One could think of parsing the XML but
> > that will be very complicated when the doc is incomplete. The easiest way
> > (I can think of) is to disallow empty lines (i.e. "\n\n") in commands and
> > close every command with an empty line. I think that's a very common
> > technique for text based protokolls.
>
> I'm not convinced with using newlines to denote new commands. XML does
> allow newlines inside the document, and I don't think we can reliable go
> against that without breaking things somewhere in the future.

sure we, can. just remove any double newlines from the buffer before sending. 
Even if you use non blocking IO you have to define some "end of message" or 
"end of command", The only other option is some <command></command> XML-tag, 
but you will not be able to look for this tag with a XML-parser, you will 
have to look for te </command> string by hand. using "\n\n" is pretty common 
(e.g. http requests ;-). Another alternative would be a 'length of command' 
header (used in http reply's) but I don't see why we should increase the 
traffic.

> I am starting to think that using a SAX parser from the outset may be the
> correct approach. It allows us to parse "what we have recieved so far", and
> perform a command once it has been completed.
>
> It is easy for instance, to know that we have started a command (we have
> recieved the first tag), and it is easy to determine that a command has
> finished ( we parse the closing tag for the command.)

Implementing a Parser for complex document structures is more comlicated with 
SAX but if it can handle incomplete XML tags it might be worth it. Also it 
will probably have lower latency compared with DOM.

Cheers,
Rolf

***************************************************************
 Rolf Dubitzky  
 e-mail: Rolf.Dubitzky at Physik.TU-Dresden.de
 s-mail see http://hep.phy.tu-dresden.de/~dubitzky/
***************************************************************