> A task on my todo list for next year (unless someone beats me to it -
> and they might) is to automatically fetch any urls exported to memopad.
> This would probably work like AvantGos form manager, which is not
> optimal, but does work.
Based on this approach, my concerns have always been:
1.) A conduit has to be written that queries MemoPad for the
records (Mike already wrote one awhile back as I recall, and I
know is it easy to do, but again only would work for
non-Windows to start with).
Once the MemoDB.pdb file is read (or Notes on the newer Palms,
the API is not the same), that has to get formulated back into
a fetch for the urls listed there.
a.) How do you correlate which url was linked in which
page, such that you can "rebuild" that .pdb with a
deeper maxdepth, one which now includes this "offline"
url?
b.) If you know that offline_url_a came from pdb_5, you
have to make sure you can rebuild that same pdb_5
document with that new maxdepth (we still don't have
granular-enough fetching to say "I want a maxdepth of
10, but only through this path of URI members.")
c.) How do you update the "read" and "unread" records in
the document metadata? Or do you?
2.) How do you do this in a way that does not require the Palm to
be in a cradle? Many of us are doing automated fetching,
without any Palm device directly attached at gather/parse
time.
The original Plucker parser was done in awk, and later in
perl, and it would build the .pdb dynamically over the serial
port, from locally cached record pieces. We no longer do that,
so unattended, disconnected functionality should still be
retained.
This means a conduit which can read a syncronized MemoDB.pdb
file from _disk_ as well as "live" from the Palm itself,
should be considered (either approach is easy to do).
Obviously you need to fetch the record from the Palm itself,
batch up the urls that are contained in it, reference that
with the "parent" page that they came from, and re-fetch with
the new urls appended.
a.) Do you use a local cache to avoid re-fetching all the
same content except that new maxdepth?
b.) Do you just consider the "offline" url you are now
fetching to be a "new" document, with this url as the
parent url of a completely new fetch?
3.) With the requests to get HTML form data processed, it would be
a good idea to integrate this same fetch-from-the-Palm
functionality to interleave well with the not-yet-added forms
support. Make it malleable enough so that it can work in that
context. Generally, this means NOT using MemoDB (guaranteed to
continue to change as Palm releases new handhelds or
deprecates the application entirely).
a.) Keep a Plkr-DocName-Offline.pdb metadata file (or
stuff it in the same metadata file that we are already
using now).
Forms are a bit more complicated, and should be considered when
designing anything that fetches data FROM Plucker, dances with it, and
pushes the results of that BACK to Plucker, whether they be offline urls
or form data or anything else.
1.) Fetch offline url/form data from Palm handheld
2a.) Correlate offline urls with parent urls, build fetch table
that includes all of the original fetch parameters + offline
urls. These aren't currently stored in the .pdb itself, so
that has to be maintained somewhere, in a cross-platform
portable way. With just a .pdb in-hand, I can't tell what
maxdepth, image width, etc. was requested when building it.
or
2b.) Take form data and submit a POST to the parent URL, receiving
response (error or success), and processing that response.
3.) Build .pdb with new url data/form response data
4.) Store/Send to Palm handheld.
Doing it in this way, reduces the need to merge or duplicate code
between the two nearly-similar requirements (offline urls vs. form data
processing).
There are probably a lot of other design criteria here, but the
above should at least be considered when architecting this new feature.
Also remember that there are something like 4 different parsers for
Plucker, in various states of completeness and functionality. Don't bind
the functionality too tightly to Python itself, lest we orphan off the
other parsers and distillers (Bill Nalen's C++, JPluck, Python, and my
Perl derivitaves).
d.
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
