David A. Desrosiers:
> > 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
You're much more ambitious than I.
My plan had been to read the MemoPad database on the desktop.
A custom database would be better, but would require changes
to the viewer -- and once one way is working, it isn't that much
work to support the other in a parser. (Supporting a live conduit
is different.)
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.
> 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?
Long term, I intend to restore the cache, so this may be possible.
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.
> 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.")
Actually, (at least) the python parser does have support for this
through linkdepth attributes; I haven't tested it, and don't intend
to use it in v1.
> 2.) How do you do this in a way that does not require
> the Palm to be in a cradle?
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.
> 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).
Live will not be v1, though if it is really easy, it may come later.
> 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.
Forms (and cookies, password, referrer, depth>1, exclude
patterns, etc) are fairly trivial adds once
(1) The parser can do them easily for a normal channel
(2) The viewer can send the information back to the parser.
(Well, once it can do so by itself, without hand-editing.)
I will be working on (1) (I've started, but not got far enough
for other's use). (2) is not yet happening, and may not until
either I start working on the viewer, or I'm ready with very
specific requirements. But memopad can handle arbitrary
text, so the conduit itself is not the tricky part.
> Make it malleable enough so that it can work in that context.
> Generally, this means NOT using MemoDB
I agree that a customer db would be much better. It would
make things easier if we want to do it "right". But it isn't
required, and something that doesn't require changes to the
viewer is a useful first step.
> 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).
I do not yet propose any viewer changes.
I don't know how to make parser changes generic beyond
the parser.
-jJ
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
