I certainly would not get confused, but there is a matter of spending the time as a beta tester. Right now, JPluck is the slickest solution I've seen. So much so, that I am not spending any time on other parsers. The ability to apply XSLT, changeable user agents, cookies support, superior speed, etc. makes JPluck my default choice. I'm actually surprised that deploying Java on end user machines is an issue for you or your company since it is so easy. In any case, my two cents is that time is the big issue.
The question of multiple parsers is a sticky one. I submitted a few minor fixes and features to the Python parser (which got in), did some work on Desktop, and then moved over to JPluck which rendered all my previous work moot to my use. (But it did enable me to drop Python off my system. Nice language, better than Java in some ways, but I've got a lot of those already.) And David has been working on a perl parser, I remember, but not THE perl parser, which is apparently different. Such a lot of technology and parser choices!
My fear is that the features will diverge across platforms significantly at some point, based on the preferred language on a platform. When a particular translation or port was done almost entirely by one person and that person drops out, the code often becomes abandoned.
Bill, question for you. You stated the goal as being to eliminate the need for perl/python/java. Would the possibility of compiling JPluck with Excelsior Jet, into an EXE, solve it? Is there an equivalent Python-to-executable compiler?
On the other hand, if there were three current and largely-equivalent platforms to choose between, Java/Python/C++EXE, I would point my relatives and less technical folk to the C++EXE version. Even installing Java (or a recent version of it) poses a huge problem to many non-technical users.
-Tony McNamara-
_______________________________________________ plucker-list mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-list
