FWIW, I did a lot of work a while back translating the Python code to C++. This is all done on Windows with VS 6.0. I've got a stand alone parser and a complete Palm conduit working using this code. We use it every day in production where I work. I started this to have a real conduit that would work for Palm users who only know how to press the hotsync button. We looked at remotely preparing the content and having them sync the pdb, but it would have been more complex for the users. Since Windows users are typically less sophisticated than *nix users, we need to keep things as simple as possible and as standard as possible. I think *nix developers drastically under estimate the simplicity needed for Windows users (but not developers ;-).
There's a couple of drawbacks to this approach though. The code base is using Python so it would be up to me to keep it in sync with the Python code, not difficult, but not trivial either. It also adds one more option to the Plucker project that probably doesn't need to be there. Also, aside from the Windows conduit produced (and probably Mac as well), the code would be useless to the other developers. I think the work that Bill J (?) is doing on getting a Java version of the parser built directly from the Python code is GREAT. This would solve a lot of problems for me. I wouldn't have to keep the C++ code in sync and it could be built directly into a parser. I think this would become the parser of choice on Windows. I'm looking forward to getting the latest version to start working on a conduit from it. Once the Java version is stable, I'll drop my C++ conduit in favor of it. I think a good conduit option is the only thing missing from Plucker (well for most Windows users to really use it easily). When I ported GKrellM to Windows it took me a long time (probably a week) to get all the libraries needed and to get a clean build. A build on Windows had never been done, so I wasn't surprised that it took me that long. I feel the same way about Plucker. I would expect it to take a long time to build since (almost?) no one seems to develop on Windows. I've stayed away from the viewer code simply because I know it would take some time to get it running and others seem to be doing a great job of fixing/updating the code. I don't blame them for not having the correct imports and stuff in there if they don't know what to put. It's up to the Plucker Windows developers to get it working and tell them what to add. For example, Bill J (again ?) has made a GTK viewer on *nix. Since the GTK libraries have been ported to Windows, I took a shot at compiling it under MS VS 6.0. I needed to make a bunch of import/define changes to get it to compile and run (found a couple bugs too :-) I have yet to get back to Bill with the required changes, but I will when I see the next version released. This is the way most projects I've been involved with go. It's a frustrating build process, but hopefully only one person will have to go through it. Bill _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
