Bill, what is the relative speed of the C++ parser/conduit to the current Python parser?
I ask because I have written several cross-platform multithreaded TCP/IP servers (and clients) and could perhaps take a good shot at making it cross-platform. Unless there's a LOT of MFC, usually it's pretty straight-forward in terms of code changes. But if the speed is nearly the same, the project momentum is much more important. Tony McNamara At 08:55 AM 9/24/2002 -0400, Bill Nalen wrote: >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 _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev