> You're much more ambitious than I.
I've thought this out quite a bit over the last 5 years =)
> My plan had been to read the MemoPad database on the desktop.
Not a good idea, generally, because the one on the desktop will
ALWAYS be "older" than the one on the Palm, especially when the one on the
Palm is the the one where the "unavailable" URLs are put. When you're
using Plucker, say on the subway, and you reach a URL in a doc that is
"beyond" the maxdepth used to create it. You add that to MemoPad, and get
to work, and sync Plucker. You _must_ communicate with the MemoDB.pdb on
the Palm, to get the latest/most-current data to fetch. Syncronizing
Plucker doesn't always include a full-sync which pulls the MemoDB.pdb from
the Palm (and in most cases, i.e. Unix/Linux, it explicitly will NOT
include that data).
> Export-to-Memos already contain an URL. They do not contain post data
> or auth info or referrer information or cookies - but these can wait for
> v2, particularly since the parser can use the defaults for that host.
But the point of that was.. where are these defaults kept?
With a .pdb on disk, and ONLY a .pdb on disk, can you
programatically tell what maxdepth was used to create it? Or what the
parent URL that was used to start spidering was? You must know this to
handle "offline" URLs (and when/if forms are added, you'll need that
also).
> Long term, I intend to restore the cache, so this may be possible.
Adding caching back, gives a great deal more functionality. I'm
working on a better algo to deal with this in my perl spider. It's slowly
shaping up, but still not in any releasible state yet. The cache data
should probably agree on a common format for records.
> Short term, I have no intention of doing so. The new pages will appear
> as separate 1-page channels (or pages off a dynamically created
> "Requests" channel), without any linkage to their original context.
> Not ideal, but easier to do, and requires no viewer changes.
Perhaps we could create a pseudo-link between them, such as (in
Library view)
[ ] My Document Name | 492k
[ ] offline-My Document Name | 50k
Indicate that the document is related, by prefacing the title of
the document name with offline-$DOCNAME, or some such. This will be a bit
weird if the user sorts alpha or with other criteria, but it is better
than:
[ ] My Document Name | 492k
[ ] Freshmeat | 20k
..where 'Freshmeat' contains the starting point of offline links.
> Work from the desktop's copy. It will take two synchs to get the
> results (at least initially), but you won't have to wait around while it
> happens. Since you're already waiting (hours/days/weeks) until the
> first synch, this doesn't really change how responsive the application
> is by very much.
Assuming the user syncronizes that data to their desktop, where it
can be reached/accessed by the Python distiller code. Having to do two
syncs is going to cause pain, for those who have created conduits that run
Plucker at each sync, for example, though that is a special case and will
probably break in a very ugly way on Windows, since you have to deal with
the .dat version of the files, and not the .pdb version, unless the user
has Backup enabled. What if they're syncronizing to Outlook instead? The
newer Palms do this by default, last I heard.
Even more reason to create a Plucker-specific datastore for this.
> But memopad can handle arbitrary text, so the conduit itself is not the
> tricky part.
Storing this data in 'text' isn't efficient, and prone to
accidental deletion by the user or botched conduit actions (Desktop
Overwrites Handheld, etc.), or those who simply don't use MemoPad (again,
newer Palm devices default to using "Notes" for that 4th button now, and
MemoPad is being deprecated in future Palm devices.
Storing it as binary makes it smaller, and generally faster to
manage (no need to write "parsers" for the textual elements in the text
record).
> But it isn't required, and something that doesn't require changes to the
> viewer is a useful first step.
Of course, proof of concept using the MemoPad records is a good
start, but I wouldn't wed myself too tightly to that format, as it is out
of our control, and will likely create multi-device incompatibilities, if
the format changes between vendors.
> I don't know how to make parser changes generic beyond the parser.
March on, sounds like you've got a good idea for deploying it.
d.
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
