[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [coldsync-hackers] patch: SPC & netsync



On Thu, 1 Nov 2001, Andrew Arensburger wrote:

> is used), so I figure the Right Thing is to split io_close into two
> methods: io_close should just "close the file descriptor," whatever
> that means for the current protocol stack, and io_tini should clean up
> the currently-used protocols. io_tini should be the very last method
> called.

So would there be instances of io_close and io_tini being called in
different contexts, or different places (that is, not just
io_close();io_tini())?

> 	Once this happens, it should be safe to replace the bogus
> close(pconn->fd)s with io_close(pconn)s.

OK.  I'll look into doing it, but since I don't have the means to test
_serial.c or _usb.c, any changes I make will need to be examined by
someone who can run them :)

> 	If anyone wants to do the above and submit a patch, that'd be
> keen, since a) I'm busier than usual at orkplace, and b) life seems to
> be throwing a lot of Shiny Things(tm) at me to distract me.

Ditto.  I've got a senior thesis to finish, in addition to this 'work'
stuff.

> 		N_("\t-t <devtype>:\tPort type [serial|usb|net].\n"),

> 	The problem with the above is that the string "serial|usb|net"
> should not be translated, since it lists literal strings. Can anyone
> suggest a good solution? Would vprintf() help?

I'm not entirely clear on how N_ works, but it seems like sprintf would
help-

sprintf(tmp, "%s [serial|usb|net]%s\n",
	_N("\t-t <devtype>:\tPort type"), _N("."));
const char usage *usage_msg[] = {
	...,
	tmp,
	...
}

This brings up another issue, though- libpconn uses printf() for user
interaction, which is not at all appropriate for a GUI (especially when
not started on the command line, as one might do in an X Window GUI).
It seems that the approach taken by UWash's c-client library, that of
application callbacks into the library, is a good approach; perhaps an
argument passed to new_PConnection.  A two-argument function- one a
string, one a log-level kind of attribute -seems the most appropriate.

I would actually prefer something a little bit more reach, to more
easily distinguish at the application level between 'information' and
'discussion,' but I'm not sure what right now.
-- 
 Matthew Weigel
 Research Systems Programmer
 mcweigel@cs.cmu.edu ne weigel@pitt.edu

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.