Re: Restoring a pilot



> There are two points here.  First, there's no way in gnome-pilot (that I
> could find) to restore a pilot.  Second, it's very easy for someone to
> lose a LOT of important data by doing things wrong.

	I'm interested to understand the use-case scenarios where someone
could "lose" their data doing these things wrong. You had a blank Palm, and
wanted to restore existing Palm data to it, from the desktop. How would you
lose data there? Backing up the blank Palm to your desktop, instead of going
from Desktop -> Palm?

	We should begin to understand them, so we can build in some
protections to prevent users from losing data or destroying the ability to
function with their devices (i.e. restoring a T3 backup to a Palm IIIc for
example).

> Okay, rant over.  I would be willing to participate in design and coding
> to make restoring a PalmOS device possible in g-p, time permitting, and if
> there is interest here...

	There is some very interesting work going on right now that will
soon make this painfully easy (oo, bad choice of words, but..)

	Basically all of the "conduit" actions you now know in pilot-link
(pilot-xfer --backup, --restore, and so on) are moving to a model where they
are shared resources (libpalm_restore.so, libpalm_backup.so or similar).
There is also going to be a global configuration file (and a user-specific
one, ala POSIX standards) so you can specify the action you want to take,
when invoking these conduits. Handheld wins, Desktop wins, Sync, Ignore,
etc. This is also going to complement the XML storage back-end we're working
on for the atomicity of Palm data on the desktop side.

	The other piece that is being worked on (in theory, while code is
being restructured to handle these slight interface changes) is that you
should soon be able to call a standardized "query API" from your app, to do
things like "SetBackend('jpilot')", or "SelectAllContact()" and so on.

	It's a very different model than we're currently used to using, but
it will prove to be MUCH more flexible and scalable than what exists today.

	Here is one example of that design, as a proposed first-pass:

	http://code.pilot-link.org/future_design.png

d.




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