|
From: Rui N. C. <rn...@rn...> - 2004-01-28 12:47:08
|
Hi benno et al.
A couple of weeks ago I've sent here a note about my early LSCP
(LinuxSampler Control Protocol) implementation, which I've named liblscp.
I've been kind of idle while waiting for comments about it, before going
any further, into GUI development that is.
You can check it out from:
http://www.rncbc.org/ls/
Christian suggested that the parser should be improved towards a
yacc/bison solution, but I think that for a preliminar and working
implementation, a simple and crude parser suffices (with the supplied one,
which is strtok based, nothing can get simpler :), at least as the current
protocol draft is about.
The way liblscp is designed and in it's current implementation, which is
just a wrapper to socket communication threading, there's no tie to the
parsing method whatsoever. As the parsing should be accomplished at server
callback context, it is of the server responsability to choose whatever
mechanism it pleases to parse each client request.
However, the helper functions supplied in lscp_parser.c are already
available shall we take the hands-on approach. OK, a bunch of hardcoded
if-else's is implied but I cannot find better solution, in code-path
performance I mean ;) If you look at server_callback function on
lscp_server_test.c you know what I'm arguing about ;) Note that all the
tests to parse every possible client request are already there, at least
as of current LSCP document draft.
OTOH bison/yacc/flex/whatever are a total mistery to me, so someone else
has to come for the rescue :)
Bottom line is, I'm eager to start some GUI code ;) and I think that it
would be nice to start the server-side callback code ASAP and integrate it
on linuxsampler.
Again, can't wait for your comments.
--
rncbc aka Rui Nuno Capela
rn...@rn...
|