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

["J.D. Smith" <jdsmith@astro.cornell.edu>]

Andrew Arensburger wrote:
> 
> 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.

I say drop it.  To heck with graffiti.  Or, if you wanted to turn
yourself all around, you could pre-cache all install databases' OKNEWER
flag (it's in the database downloaded, right?) just after post-install
conduits run (when the final install list is generated), and only do the
transfer if one of them is set.  Infinite desktop speed, remember.  Does
OKNEWER only apply to deleting/replacing, not record updates?  This
method presumes that, but I suppose you could scan databases in backup
also for dirty_records+OKNEWER.

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

Hmm, I guess I know next to nothing about the sync sequence, but would
it be a problem if the ordering got switched around?  Suppose only late
in the sync did you realize you needed the user info.  What havoc might
that wreak?  I played with testing the startup stuff only... downloading
the database list, etc.  Takes about ~6 seconds for all of that, which
isn't really too bad for an entire sync, but for just a quick install,
this might like to be reduced.  It doesn't seem the true duration
reflected in the Mode button icon on the Palm when going through a
sync.  

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

To my way of thinking, restore is recovering, not destroying data....
presumably there's nothing on there you want to keep, either it's
deleted or garbled, and you want the desktop copy to overwrite
everything.  Install, however (or upload, or whathaveyou), might only
overwrite a specific thing.  The prospect of an accidental restoration
might indicate using a long option, only, for this:  coldsync --restore
or even coldsync --recover (or -mrestore/-mrecover), and relegating the
more common operation, uploading a given file, to a simpler switch.

Question: if a resource database is installed with coldsync -mr or
pilot-xfer or some other means, and doesn't exist (or does exist?) in
the backup, does ColdSync back it up?  Does the ColdSync upload try to
put a copy there?  I think making a backup would be the most logical
course of action, but as far as I know ColdSync doesn't ever download
.prc's.  

JD

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