> > Yesterday I looked into using activestate perl on windows to run the > client. I used the standard client (1.0.3d) and I actually got the > threads up and running and got rid of many problems on the way. The > problems were very easy to fix, for instance there are numerous > references to absolute and relative paths where stuff should be (like > here "if (-e "$ENV{HOME}/.pskmail/.pskmailconf") {") and those are just > a find/replace away from fixing. Other times there were absolute > references to stuff that should be within "/usr/local/share/pskmail" and > thats just as easy to handle. Anyway, I debugged and got it as far as > starting up and running stable without producing errors on its own (but > I didn't interact with it in any way). > > That is to me proof that perl+gtk is able to run "native" on, at least, > both operating systems. So, what we could do is to clean the code and > lift its abstraction level so that it works in a more OS general way. > That would give us one code base that runs on several operating systems. > Is that what you are actually doing? > Hmmm..., interesting. I'd like to give it a try. Can you send me the working stuff so I can give it a whirl? > Also, when I did this I started to think that perhaps we should use what > we have as a test version only. Perhaps we should produce a proper UML > foundation and use that to generate code for something thats truly able > to run on several operating systems without modification. The way pskmail has been developed you could at best call it a 'fully working prototype'. I would be in favor of cleaning/redesigning/recoding it to run platform-independent, and use the present implementation as the reference application. We could/should leave the servers on linux and make them run on a LAMP server (do away with X and operate/monitor it via the web server). > I would argue that object pascal in fpc/lazarus would be a good way to > go, I guess others would suggest java or even c# and mono. > This is all stuff I am not (yet) familiar with, but that is not so important as long as the development environment is on Linux :). > But, the main thing I am looking for is a way to keep the forces united > on one codebase so that what you and I do benefit us both, not the other > way around. If this new client of yours deviates from the original > client then we won't be able to answer questions or support it in any > way. When the beginner starts to ask questions then you will have to > take care of these. Also, as these questions will differ so much I guess > you'll eventually want another channel to handle those, i.e. a new > mailing list... So the fork of client will also result in a fork of > users... > This is not necessarily bad, a lot of the functionality of the intermar implementation is specific for their application (maps, grib data, WX broadcasting, APRS focus etc...). Moreover there is the language barrier, a lot of users don't use our list because they are not fluent in English... The goal should be, however, to retain the common code base across platforms to prevent duplication of resources.... 73, Rein PA0R -- http://pa0r.blogspirit.com