[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [coldsync-hackers] speed
On Friday 17 October 2003 11:53, Andrew Arensburger wrote:
> > //filling up the request with a no-op...
> > requestheader.op = SPCOP_NOP;
> > requestheader.status = SPCERR_BADOP;
> > requestheader.len = 0;
> >
> > write(SPCP, &requestheader, 64);
>
> I think so, except that
> - When you're sending a request, you don't need to fill in
> 'status'. That will only have a meaningful value in the
> response.
> But this allows you to use the same 'struct spc_hdr' for both
> the request and the response.
> - You're sending 64 bytes, consisting of 'requestheader' (8
> bytes), plus the 56 bytes after that. If you're lucky, this will
> cause a segmentation fault and you'll find the problem. If
> you're unlucky, it'll work, and 'coldsync' will see random
> garbage and try to interpret it as an SPC request.
Andrew, I was curious and had a quick look...
Correct me if I'm wrong, but instead of implementing another SPC stack,
couldn't he just link his C program to libpconn and use spc_client/dlp_cmd
directly? That _appears_ to be what it's for, but I'm not sure how far the
implementation goes towards what is needed.
Something like this (but with more error handling):
#include <spc_client.h>
#include <dlp_cmd.h>
struct dlp_sysinfo si;
PConnection* pconn = new_spc_client( atoi( SPCpipe ) );
DlpReadSysInfo( pconn, &si );
fprintf( stderr, "PalmOS ROM version %u\n", si.rom_version );
If that doesn't jive with the SPC "server" that conduits.c is running, how
much extra magic would be needed?
c.
This message was sent through the coldsync-hackers mailing list. To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body. For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.