Re: [coldsync-hackers] ColdSync 1.5.0 snapshot (and RFC)

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

On Mon, 13 Nov 2000, John-David Smith wrote:
> Andrew Arensburger wrote:
> >         coldsync -mr /my/file.pdb /my/dir
> > 
> > copies /my/file.pdb , and every database in /my/dir to the Palm. Since you
> > can specify individual files, you can use this to install files.
> 
> Sounds good.  I wonder if it should even be called "restore" then.  This has a
> sense of "recover to a prior state after some big screw up", in most Palm
> circles, which of course it can be used to do,

	Well, I thought of having "-mi(nstall)" be a synonym for
"-mr(estore)", but I held off on that because the notion of a separate
install mode that runs Install conduits intrigued me.

	Oh, and I looked into why it takes restore mode so long to start
uploading files. It's annoying:
	If a database is open by another application, you can't delete it
before uploading a new copy, unless its OKNEWER flag is set.
	You can't fetch the flags for a given database; all you can do is
fetch the flags for _all_ databases, then find the one you're looking for.
	The function that fetches this information about databases needs
to know how many databases there are; for this, it needs to get
information about memory and whatnot.

	This is annoying because the only database that's affected by this
is "Graffiti Shortcuts", yet it causes a noticeable delay for all
databases.
	Right now, I'm tempted to punt: if DlpDeleteDB fails because the
database is open, print an error message saying what happened, and telling
the user to do a full sync.
	In the longer term, I think it would be cool to redefine 'struct
Palm' which keeps all of the information about the state of the Palm on
the other end of the connection. Instead of having functions look at its
fields directly, define a set of C++-style accessor functions, e.g.,
instead of
		struct Palm palm;

		GetMemInfo(&palm);
		for (i = 0; i < palm.num_dbs; i++)
			...
use
		struct Palm palm;

		for (i = 0; i < palm_num_dbs(&palm); i++)
			...
The first time it's called, palm_num_dbs() would call GetMemInfo to find
out how many databases there are on the Palm. On subsequent calls, it
would simply return the cached value.
	I believe this would help improve the efficiency of the program
(data isn't fetched until it is needed), and its readability (right now,
there's lots of initialization in main(), and it's not always clear what
it has to do with anything, or which of it is necessary).

> In some sense, an additional "restore" mode which simply uses the backup/
> directory from configuration data to recover the state of the device, without
> any command line arguments required (or accepted), might be clearer.  
> 
> User: "Oh no I dropped my Palm into the toaster, and it reset."
> 
> %coldsync -mrestore

	I thought of having a default like this (actually, I though of
having "coldsync -mr" default to "coldsync -mr ."), but decided against it
because restore/install mode has the potential to destroy user data. By
forcing the user to type <space><dot>, it guards somewhat against typos.

> P.S. One issue with ColdSync that I feel might need addressing soon is status
> message reporting.  Currently, the conduits can report various things with
> various levels of urgency, which may or may not be reported based on the debug
> level settings.  What is missing is the level of info the casual user (not the
> conduit programmer) who likes to get feedback might want.  Something like a
> verbose (-v) switch, which may or may not map directly onto some combination of
> facility:level pairs.

	It should be fairly easy to come up with a set of "canned"
facility:level pairs. However, no one has come up with a concrete set of
levels.
	(Note in passing: the TRACE_* messages are all in English.
Messages printed by "-v" should be translated.)

-- 
Andrew Arensburger                      This message *does* represent the
arensb@ooblick.com			views of ooblick.com
When things look dark, hold your head high so it can rain up your nose.


-- 
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.