Re: A New Package

Steve> It is free software, so, in your eyes it's not a dilemma? Right. If you have the resources to provide more than one port, great! If not, it's not your responsibility. The only thing that we'd like is a polite response to the occasional inquiry about when you plan to port to Platform X. :-) That response can be a flat "never" and still be polite :-) What is undesirable is the addition of code to XEmacs itself which is specific to an operating system or external library. This makes maintenance and further development much more difficult. For example, the XEmacs event loop is extremely complex. We would prefer to have only one version, and recently the TTY version has come a long way to being integrated with the X version. We don't have any choice about a separate version for NT if we want to support NT. But until recently this consideration was sufficiently important that no serious effort was made toward a Gtk+ or Qt port of XEmacs, despite the obvious attractions. It was considered that the Xt version of XEmacs should be satisfactory for users who also have the Gtk+ and/or Qt toolkits available as the greatest common divisor. This doesn't apply to an external binary. Although I am not a networking expert, I don't see any reason why code to implement UDP in XEmacs would be so platform-dependent that it wouldn't get refined automatically as part of the process of beta-testing. So that shouldn't be a problem either. Steve> Well at the moment I have no interest in doing anything Steve> with it except for using it for ICQ in XEmacs, so I guess Steve> that would make it pretty well Emacs-specific. I have put Steve> it in ./lib-src (figured that would be the best place for Steve> it). The point is not what you intend to do; it's what other people might make of it. A general purpose tool would spread more rapidly if presented to a general audience rather than as a specific widget buried in the depths of a huge application like XEmacs. But as long as it's free the important thing is to get it published. A good tool will eventually be discovered and popularized. Steve> Should I just submit the package as is and mark the Steve> description "For Linux x86 only - please port me"? Yes, but I would phrase that as "developed and tested on Linux x86; only supported on that platform" (you do plan to support it with the occasional bugfix and coordinating 3rd party contribs, right?) How much you do is up to you, but if it's clear you're going to orphan it immediately it's much less likely to be integrated with XEmacs. It is certainly kosher to ask someone who submits code to port to another platform if they would be willing to help maintain, or at least test, that port. Steve> Would there be any advantages to having it as a module? Or Steve> would it just be a waste of time? Modules are a good thing, some think, but we need more examples. This would be one way to achieve Daniel's suggestion about adding UDP support to XEmacs. It shouldn't be hard, since TCP and multicast support are already present. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."