Re: [Linuxsampler-devel] Lates CVS commit

[Christian S. <chr...@ep...>]

Hi Rui, hi Vladimir!

I reply to your mails together in one...

Am Montag, 8. M=E4rz 2004 12:09 schrieb Rui Nuno Capela:
> Current linuxsampler server does NOT respond as soon as a valid syntax
> command is received.
>
> For example, when a client sends just "ADD CHANNEL", the server seems to
> wait for an additional character before it responds.
>
> If otherwise the client sends "ADD CHANNEL\n", the server recognizes the
> command properly and responds right away. In fact, it ONLY responds when
> any other character is present, not necessarily "\n".

The parser waits until the command line is terminated, this can either be=20
"\r\n" or "\n" or EOF, thus if you just send "ADD CHANNEL", the parser=20
actually calls the AddChannel() function when you close the network=20
connection. You will see that on server side when you increment the debug=20
level.

But to solve this misapprehension now once and forever; every command line=
=20
should be CRLF terminated. I updated the protocol document therefore today.

> Chris, I'm willing to devel into your bison/yacc nightmare :) I'm still
> insisting in patching liblscp into the linuxsampler server, but this time
> using the bison based parser. Yes, I'm telling you that I can get rid of
> my handcrafted-pseudo-parser but sticking with liblscp.

Why do you think bison is a nightmare? Of course, things you are not used t=
o=20
are always less convenient than things you know, but you will see that this=
=20
solution is pretty simple, very easy to maintain and it will definitely pay=
=20
off when this protocol grows in complexity.

Regarding your liblscp code migrating on server side, these are the issues =
I'm=20
complaining about:

a) I'm against a hand-crafted parser.
b) There should be a fixed amount of threads, created on application start =
and
   awaken as needed, instead of creating a new one on every client connecti=
on.
c) I don't want to see client code in the LS codebase.
d) I prefer the server side completely to be implemented in C++.

Regarding c) and d) I suggest to split liblscp into two parts, so liblscp j=
ust=20
contains the client side and will be commited into CVS as separate module,=
=20
whereas the server side goes directly into the LS codebase. I really don't=
=20
want to blow the LS codebase with code we don't need in the LS engine anywa=
y.=20
There's only one file that should be shared by liblscp (the client side) an=
d=20
the server side in LS: one header file containing defines for warning and=20
error codes (currently meant to be the empty file src/network/lscp.h). The=
=20
last point d) is of course more a matter of taste, but as the whole=20
application is written in C++, I also like the server to be and it should=20
take you only a couple of minutes to refactor your server code from C to C+=
+.

If you'll solve these four issues, than I'm very happy to accept your=20
solution.

Am Montag, 8. M=E4rz 2004 15:39 schrieb Vladimir Senkov:
> In other words, we should be able to automate EG testing, etc. test gigs
> should be perhaps generated but I don't think we currently have support
> for that in libgig . . .

It's not currently. It would perhaps take about 2 - 4 days to extend the li=
b=20
so it's also capable to create and edit .gig files. I thought about it, but=
 I=20
don't think it's important at the moment.

Am Montag, 8. M=E4rz 2004 15:58 schrieb Rui Nuno Capela:
> How do you think we can feed the parser with input from a callback? I know
> that the redefined YYINPUT macro is the place to look, but it does not
> seem to accomodate the callback model, at least directly.

That's one of the points why I left the server single threaded. As it's not=
 on=20
my priotity list, I haven't really looked into this subject, but there is o=
ne=20
solution that comes to my mind: a fifo, then we can even completely drop to=
=20
override YY_INPUT and just set the input file descriptor to the fifo (inste=
ad=20
of the standard one, which is stdin). We should research for other solution=
s,=20
I don't think we're the first ones using flex/bison within a network server.

CU
Christian