Re: [coldsync-hackers] New snapshot: 2.2.0

[Andrew Arensburger <arensb+CShackers@ooblick.com>]

On Wed, 8 Aug 2001, Mike Durian wrote:
> On Wed, 08 Aug 2001 12:05:21 EDT, Andrew Arensburger <arensb+CShackers@ooblick.com> wrote:
> >	Bugger. Have you tried it with
> >		protocol: net;
> >in the listen{} block?
>
> I just tried it.  Still no luck.

	Bleah. I'd love to help, but I don't have an m50x[1]

[1] Though the Visor that I'm currently using for day-to-day stuff is a
bit thick for my taste. If y'all want to pass the hat and buy me an
m500[2], I'll be grateful, and much more able to debug.

[2] I don't care for color.

> I'm going to think aloud here for a moment.  From a polymorphic
> view point there are two ways to handle the palm protocols vs.
> physical interfaces (including different USB implementations)
> combinations.  You can start with the palm protocol and select
> an appropriate physical interface polymorphically or start with
> the physical interface and make a polymorphic call to the
> appropriate palm protocol.
>
> My patch, which bounced, did it the first way.  I used compile
> time #ifdefs on the OS to select an appropriate physical interface
> for a palm protocol.  Your current code uses the other approach.
> It starts with a physical interface and uses a switch statement
> to select the correct palm protocol.  I can't really think of
> a reason why one approach would be better than the other.

	The current setup is due to historical reasons.
	A more generic approach would have modular code, and you'd specify
in the config file the exact protocol stack you want to use.

> However, I do think there can be improvement on using the #ifdef
> or switch() statements.  The rest of the code uses function pointers
> to hide the polymorphism.  I think that's the correct approach for
> this too.  That way you don't have to worry about using a switch
> statement to unwind the different protocol stacks at all the exit
> points.  Instead you just call (*palm_proto)->unwind().

	Agreed. The code currently looks the way it does because I wanted
to get something working, and later get it working prettily (see Fred
Brooks's comments on "growing software").

> I'm not sure what you do when you have OS specific code that won't
> compile under other OSes (BSD USB vs. Tru64 USB).  Just tackle
> it via autoconfig?

	Yeah. See libpconn/PConnection_usb.c : 'configure' figures out
whether or not BSD-style USB is supported, and sets 'WITH_USB'. All of
libpconn/PConnection_usb.c is enclosed in a "#if WITH_USB" block. Not
terribly efficient, but it works.

-- 
Andrew Arensburger                      Actually, these _do_ represent the
arensb@ooblick.com                      opinions of ooblick.com!
                        Generic Tagline V 6.01

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.