> If I may indulge in a moment of "air programming", the real solution > would be something along the lines of "phpJpilot", in which the > back-end logic from j-pilot and pilot-link is preserved, but the gui > elements of jpilot are translated to php, and adapted for > web-browser display. PhpJpilot would run on some master box with a > web server, and PDA sync would be handled either locally on that > machine or remotely using the pilot-link net sync plumbing. Have you looked at the OpenSync project? Its rumored to do exactly what you describe. Think the level of agnosticism of SOA (where client doesn't need to know anything about the server or its capabilities, and vice versa) at the Palm and data level. Frankly, the Palm is just a container, not an end-device. It "holds", and transports that data for display or integration with other things (desktop apps, web apps, over-the-air communication, etc.). Personally, I'm a fan of a certain level of integration, as long as the distinct components can be pulled out and replaced with others, which add, remove or enhance functionality. Sort of like "Mail(tm)" in the larger sense. I can pull out the server and replace it with any of dozens of other MTAs, and yet mail still goes from A -> B. Tired of that mail client? Use elm, mutt, pine, Thunderbird, Evolution, KMail, Outlook, SnapperFish, whatever you want. Mail still continues to function as normal. Modular is the way to go with a system like this, but unfortunately there are developers who believe they can, and should, own every piece end-to-end, and this is why they continue to fail time and time again. Palm as we know it is eventually going to go away. The data we keep on our Palm devices today is probably going to outlive the device itself (calendar entries, anniversaries, contact information, notes, passwords, whatever). The "new" system should be smart enough to allow a new device (as yet uninvented) that can just plug right into the existing framework that works today with Palm devices. Sync with the kitchen tabletop? Sure, no problem. Send that data to the office for the internal calendaring system there? Sure, done. I'd concentrate on the existing projects that are working on these goals, and communicate your needs to them and see if they're going along the path you need them to go. If they are, great! If not, see if they can accept your new feature requests, by explaining your needs. If that fails, take what exists and build upon it, or reinvent that wheel. I find it useful to ask people who are having trouble with an existing system/application to describe their needs or their problem using ZERO technology words, ZERO product names and ZERO existing tools. For example, instead of: "I want a php version of J-Pilot, so I can sync to an Apache server using Linux so users with Firefox and MSIE can read and print it..." That could be expressed as: "I want to be able to share my data with many people who have access to the Internet with a browser." It really does change the scope of how things get built around it, and it simplifies solving the problem in the most creative way. > As an additional benefit, printing and PostScript generation would > now be handed off to the web browser, instead of burdening the code. Someone still has to write that code. I'd much prefer to have the server-side prepare the data in a way that looks good in pdf/ps format, than have the browser try to figure it out with tables and other HTML'ish badness. pdf classes are easy to drop in now, and gives you pretty templated pdf-on-the-fly generation. It also separates the display logic from the printing logic, which is always a plus. You don't always want to print the same exact thing you're seeing in a browser. > Nonetheless, the benefits would take this already outstanding > application to a whole new level, in my opinion. All that matters is the data, not how its delivered to you. Thousands of people have been working on this for years, and since nobody wants to work with anyone else, we have 25 variations of the same theme, none of which work well at all. SyncML was supposed to solve this problem, until it was severely overburdoned with IP, patents and exhorbitant licensing, and now its dangerous ground to work with in the OSS community. > I feel a little embarrassed to be tossing this out, since I'm not > really in a position to contribute code to such a project. I'd > contribute to a bounty, though. Start with these and see if they might suit your needs as a starting point. I always find myself in the position of being the "caulk" with a lot of similar projects, never the tile. http://www.opensync.org/ http://www.jsyncmanager.org/ Be the caulk. David A. Desrosiers desrod at gnu-designs.com http://gnu-designs.com
More information about the jpilot mailing list