-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> I know this is pushing the envelope for Plucker's initial objective, but I
> feel this 2 way communication could revolutionize Plucker and the Palm Web
> Browsing market.
There are quite a few technical roadblocks that make adding forms
support difficult, and this has been discussed a few times before. Start
here for some good comments:
http://www.mail-archive.com/plucker-dev@;rubberchicken.org/msg00424.html
Here's a short list of issues we'd have to consider:
1. How do you store the form data before submission? Do you create
MyDb-Plkr-Form.pdb and store it in there? What about beaming
content? Do you beam the form data also? What if I fetched with
the --no-urlinfo flag?
2. How do you get the form data back out, and upstream to the site
again? This has a few technical issues, such as:
a. What happens if the site that you're submitting form data
to is down? Do you time out? Fail gracefully?
b. What happens if the site changes from the time you
fetched the form, until the time you submit the form
data?
c. What if you fetch site.domain.com, pull some content,
populate a form, then remove site.domain.com from your
~/.pluckerrc file and don't fetch it at the next sync,
but your Palm has data that needs to get pushed upstream?
Do we force you to fetch the updated site anyway, after
submitting your form data to retain continuity?
d. You must ALWAYS submit form data in a POST before you
receive the response from that request. If the site with
the form data is linked from a link on another page
you're also fetching, how do we know which page to fetch
"first", so we retain continuity?
3. With the number of tools we support, how do we ensure that it is
implemented properly, in a format and method suitable for
implementing in all of the tools used (java, python, perl, and
otherwise)?
4. What about the conduit that now has to query the Palm for updated
form data, pull it to the desktop, unpluck it into an HTML POST
request, push it to the server, receive the response to that POST
request, and then sync that back to the Palm. How do we make this
consistant across Linux, Windows, and Mac OSX platforms, without
losing any data?
5. How do we build the form control elements? Radio buttons,
dropdown boxes, editable form entry fields, etc. Is there
anything in the open source space that we can use to leverage
this already? Can we use the new browser built into the OS5 Palm
devices to pass form data to?
As you can see, implementing it isn't as simple as adding support
for a <form></form> tag pair, and requires quite a bit of fleshing out the
concerns before it can be added (if at all). Lots of new code would have to
be written to support it, both on the Palm side, as well as the on the
desktop and conduit side.
> Please consider it...
Every idea is considered, but some just aren't immediately feasible,
given the current design. This one has been suggested before, but there were
more important things (at the time) to get working before forms could be
considered. Take a look at what Ben Chess was working on, maybe that's a
good start towards submitting some patches.
Just my 0.02c.
d.
perldoc -qa.j | perl -lpe '($_)=m("(.*)")'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.1.92 (GNU/Linux)
iD8DBQE9yGQKkRQERnB1rkoRAsWoAJ9yTeIPeueIiXxexcxkQRT4C5DJuQCg06q6
qLOZlunjxqBUIqH1Gv+Ctfw=
=htns
-----END PGP SIGNATURE-----
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
