rfcomm_sppd -S as generic wrapper

[Maksim Yevmenkin]

[...]

> BTW, Luigi's pipe application is interesting, but what about true
> two-way communcation? For instance, I would like to have something like
>
> # rfcomm_sppd -S -c sp -a myPalm -x "coldsync -t serial -s -md"
>
> ...meaning: Upon receipt of a SP connection request from myPalm we would
> fork coldsync to synchronize the Palm (just like USB or serial sync, but
> now bluetooth).
>
> This could even go into /etc/ttys, forking a fresh rfcomm_sppd after the
> request terminates.

well, i thought about this, but not really sure how to do it cleanly.
here is what i mean. with rfcomm_pppd(8)  (lan service wrapper) we
only need to start one server and register one lan service with local
sdpd(8). as soon as client connects to rfcomm_pppd(8) it forks and
starts separate ppp(8) instance that handles this particular client.
this model works well (imo) here.

i'm not sure what rfcomm_sppd(8) wrapper behavior should be. what you
seems to be suggesting is that a single rfcomm_sppd(8) instance can
only handle single client at a time. this could be a reasonable
assumption.

> I'm currently doing this in two separate steps, first starting
> rfcomm_sppd with some arbitrary pty, then coldsync talking to that pty.
> So yes, this definitely works.

also your idea about putting rfcomm_sppd(8) entries into /etc/ttys
should work as it is, no? did you try to put rfcomm_sppd(8) into
/etc/tty entry for the pseudo terminal (slave) part and run coldsync
on mater pty?

thanks,
max