Re: usqld problem

This is a known problem,

I started to hack a solution to the above based on the existing XDR
content in the protocol, this will completely break backwards
compatilibity, which is a shame, as it is basically finished, i may as
well release it as a stop-gap.

basically i'm not sure what the best approach is with respect to the
wire protocol and i would really appreciate any advice, the requirements
are:

1) Supports call initiation by both parties. (so normal HTTP isn't quite
appropriate, although an HTTP-like protocol might be ok.) as we could
expect the client to de-couple its expectation of responses from
incoming packets. (i.e. so ad-hoc notifications could occur)

2) Content can be parsed quickly and with a small parser (cuts out XML
as far as i'm concerned, ASN.1 is a possibility but i firmly believe it
is evil, so i might take some convincing.)

3) Data rep is fairly flexible (preferably with support for transmitting
length-prefixed binary strings, although this can be don outside of the
main encoding)

so Basically my choices for content are:

Existing XDR (RFC 1014) rep
 + there is already code
 - structure isn't encoded in packets, so parsing is risky/harder.
 - it is a bugger to code in the bindings. (partly due to the way my XDR
objects work)
 + could possibly be replaced with existing RPC code,
 - backwards compatibility is a problem as changing something in a top
packet breaks the schema for all packets, and 'generalised' schemas
wouldmean unweildy packet sizes. (although this could be put in
protocol headers without being in the PDUs)

New Text-based rep (lispy probably)
 + simpler than currently, could build a parser using lemon and lex
 + C-binding would be easier (possibly)
 + can be safely parsed (see above) re-entrantly
 - no opaque binary coding
 - all numbers etc are stringified

ASN.1
 - it is evil
 - pretty heavyweight
 + its self-typed and length-prefixed so parsing is safe
 + there is definately code (see openldap etc)
 - it is probably stupidly bloated.

WBXML
 - seems to require most of the baggage of XML parsing
 + allows opaque binary content
 - not sure whether there is code
 

I have been pondering moving to a more HTTP-like protocol layer and
either a text-based network representation (which is ok for sqlite as
the data is string based anyway) or alternatively using the existing XDR
inside an HTTP type packet (which would allow you to have protocol
headers with

i feel rather silly as no /obvious/ solution presents itself.

there is of course the option to ditch everything and start again with
RPC..... which has its own advantages and disadvantages (like no means
for selecting on incoming message streams.)

blargh.

i'm going to the pub.

owen

On Fri, 2002-11-29 at 09:50, Florian Boor wrote:
> Hello!
>
> I just tried to port gpe-todo to use usqld. This was nearly trivial - exept one problem:
> gpe-todo calls queries from usqld callback functions. This seems to be ok with sqlite, but
> not with usqld. If the code tries to start the "inner" query, i get this error:
>
> usqld protocol: received rows without heads!
>
> It would be great if you took a look at this - if you don't have time or so, just tell me.
>
> I hacked a few lines to test this situation, if you like i'll send it along with the
> database that caused this error.
>
> Below you can find the parts of code causing this error.
>
> Greetings
>
> Florian
>
>
> ----------------------------
>
>
>
> static int
> item_callback (void *arg, int argc, char **argv, char **names)
> {
> if (argc == 1 && argv[0])
> {
> char *err;
> int id = atoi (argv[0]);
> // inner query
> if (sql_exec_printf (sqliteh, "select tag,value from todo where uid=%d",
> item_data_callback, NULL, &err, id))
> {
> printf("err item: %s\n",err);
> free (err);
> return 0;
> }
> }
> return 0;
> }
>
>
> int main(int argc, char** argv)
> {
> ...
>
> if (sql_exec (sqliteh, "select uid from todo_urn", item_callback, NULL, &err))
> {
> printf("err main: %s\n",err);
> free (err);
> return -1;
> }
Received on Fri Nov 29 14:04:12 2002