Thanks for the input. First, a rundown of the options I see with notes on the problems for use in my company: Python - doesn't seem to use the native http stuff so our internal servers can't be accessed (we use autosocks) Jython - have to distribute a JRE (could use 1.3 so this is okay), but Plucker Desktop isn't setup to handle running a different parser right now. And the Jython parser is still in beta (I don't even know if anyone is using it). JPluck - have to distribute JRE 1.4 which won't fly since a lot of our application code is based on 1.3 right now (there are big differences between 1.3 and 1.4 which can make 1.3 code fail on a 1.4 JRE, i.e. ActiveX bridge was dropped in 1.4) I'd also have to add support for Word documents. Perl - no idea what the status is, but Perl would have to be installed and I've no experience with it.
For me, either the Python parser/Plucker Desktop or JPluck would be ideal. However the notes above prevent me from using either and I don't think I can overcome the stumbling blocks mentioned. I agree that installing a JRE is easy to do, but it may interfere with other Java apps already deployed and our install process cannot ask if they have a JRE or anything. We use pretty much silent installs with no user interaction. Fringe wrote: >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 I'm afraid of rendering my work moot too, hence I'd rather see one or two options at most. >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. I don't think the features will diverge, or at least the resulting plucker database, since the viewer defines what is supported. I don't care so much about the options used to get the database since the options needed for my purposes are rather minimal. However, I agree that if there isn't a good momentum built up for a particular tool it will probably become 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? I've never heard of Excelsior Jet, but I've download the demo and am trying it out right now. If it can give me a standalone executable (without needing a JRE), then it may solve my problem. I don't know what will need to be done with the JPluck conduit, but I can try that out soon too and I can always use my own conduit instead. I've tried one other exe compiler before, but it didn't really leave the exe free from a JRE. >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. Since my target audience is Windows users I prefer the easiest install. I'd prefer the Plucker Desktop/c++ parser/my conduit since it would be the easiest install and would give Windows users what they expect from a Palm application. I'm guessing that for most of the Plucker developers this isn't the case. I'm guessing most don't run Windows and aren't concerned with having to use Python and aren't really concerned with the time it takes to run the parser (i.e. a cron job or something done in the background). Given that, there isn't much need for them to get involved with another parser project (the no itch thing). Any thoughts are appreciated. Thanks Bill _______________________________________________ plucker-list mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-list
