Theoretically Java is portable (but I doubt that would be that simple).
"Write Once, Debug Everywhere.(tm)"
The generic question is: with the growing number of powerful Palms that can access the internet, is their a way to create Plucker files under the Palm OS?
Lets just model this scenario for a moment.
Lets say you have a moderately small website document (an online HOWTO for example).. 20 pages, each 20k in size. That's 400k of actual HTML content to pull across. Now if each of those pages has a few images, 15k here, 30, there, you're into the lower single-digit megabytes to just store the files you pull across in cache, Palm-side.
Now you have to pre-process those pages, turning them into something that Plucker (or some other reader) can read natively, including carrying the necessary image libraries and logic to convert the images to something Plucker can also read. Now you've got something like 10-15 megabytes of processing RAM consumed just to manage this effort to convert the HTML and process the images down to something the "live" document reader can handle.
Add to that, the requirements of the running JVM in memory on the Palm itself, and things can get very slow, very fast, even with today's "fast" Palm devices and the system RAM they use for running applications.
It is for this exact reason, AvantGo went with their "man-in-the-middle" proxy system. Even if you launch AvantGo on your net-connected Palm device, and ask it to fetch a website that doesn't exist locally on your Palm, it still goes through AvantGo's proxy system, and the content it still scheduled and stored there for later requests (by you, or others). Yes, even password-protected website content. You aren't ever contacting the website "live" from your Palm when using that approach. It goes from Palm -> AvantGo proxy -> website -> AvantGo proxy (stored and pre-processed) -> Palm device.
Palm's own WebPro browser does this as well, to resize and reformat the website content for the Palm display screen size. You can disable that in WebPro, however, and view "raw" HTML data + images, un-preprocessed.
It can be done, but I don't think using Java as a way to create "live" Plucker documents on the Palm itself, is a worthwhile approach to the problem. If you're already connected, just make an online browser (like WebPro, or the other 4-dozen Palm browsers out there). If you enable the cache, the data is available to you, offline anyway.
If you're not net-connected, why waste the space and time to sit there for 10 minutes while your Palm device pulls down 400k of data and churns several megabytes of RAM to process it into a 100k document to read offline?
This is exactly why Plucker was created. We use the power and speed of the desktop processor and Internet connection to fetch and convert the data, and then sync that to the Palm using whatever sync tool you want.
The "early" Plucker contained an actual awk parser and a Perl conduit, which would require that your Palm be connected to the desktop at the time you were creating Plucker documents. It assembled the document "live" on your Palm, as you synchronized it, record by record. Then again, this was at a time when Plucker didn't support images, and the reader was only 15k in size ;)
Assuming the answer is no, what is the easiest path to get there and is anyone who can program (as opposed to us users) interested in blazing the trail?
Laurens is purportedly doing something like this with his proprietary viewer and desktop products to create that content. Check out "Sunrise Desktop" for one example.
A quick test on my end shows that it can't even make its way to through some pretty common website content (the FreeBSD handbook, for example), without completely locking up the application itself. Its a Java thing, no doubt. I've given it a ton of memory to run, and it still gets exponentially slower the more it tries to parse, until it grinds the application to a halt.
I've talked to several Java programmers already who have looked at the latest version of the JPluck code, and have given me some ideas about continuing that project under a different name, with significanly faster processing and some more features (table support anyone ;) Since JPluck is "officially dead" according to Laurens, if people want to continue using it, we need to fork it off into a separate project.
I may set up a bounty on the Plucker website to handle accepting donations to help pay for a Java programmer to sit down and go through it and fix the issues we've found. It shouldn't take that long, or cost that much in terms of dollars. If anyone wants to donate their Java programming skills, contact me directly off-list for a list of immediate tasks that need to be addressed in JPluck today.
I may revisit it soon, if the need arises.
d.
_______________________________________________ plucker-list mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-list
