evan@telly.on.ca (Evan Leibovitch) (07/01/90)
This is a call for discussion on a Usenet hierarchy dealing with applications software. During the failed vote on comp.unix.sco, one of the valid points brought up was that applications were not unambiguously dealt with in the Usenet namespace. This proposal is an attempt to deal with that problem. Specifically, the groups being proposed are (subject to change): comp.apps.spreadsheet Spreadsheets (1-2-3, Q-Calc, 20/20, Professional) comp.apps.wordpro Word processors (as opposed to text formatters) (MS-Word, WordPerfect, Lyrix) comp.apps.comm Communications packages (as opposed to protocols) (Blast, Crosstalk, Kermit) comp.apps.vertical Industry-specific implementations of databases (SBT, Fourgen) comp.apps.graphics End-user graphics software (AutoCAD) comp.apps.office Integrated office automation tools (Uniplex, WP Office, SCO Portfolio) comp.apps.database Specific end-user database products (Informix, Progress, Oracle, Integra) comp.apps.misc Anything that doesn't fit elsewhere All groups are to be unmoderated. The intent with comp.apps.db is to remove the questions related to specific packages out of comp.databases, and allow that group to deal with more general and theoretical questions. But if there's consensus that it doesn't need to exist, I'll drop it. In the discussion to date, most of the reaction has been supportive. One negative comment has been that the hierarchy should be "comp.unix.apps.*" instead. Though I certainly won't get religious about it, I believe this hierarchy belongs in comp.apps.* because: 1) Applications of a common type but on different platforms have more similarities than differences. Many applications (like Lotus, WordPerfect and others) are being ported across many different platforms. Though these packages have some porting-related differences, their look-and-feel and support issues are identical across different operating systems. 2) There has not yet been enough demonstrated traffic to justify multiple separate comp.foo.apps.* (or rather, comp.os.foo.apps.*) hierarchies. If the comments are not overwhelmingly opposed to this idea, I will issue a call for votes on this hierarchy early August. Thank you. -- _____ / \ \/\/ | Evan Leibovitch | (o)(o) Sound Software, located in beautiful Brampton, Ontario C .---_) evan@telly.on.ca / uunet!attcan!telly!evan | |.___| | \__/ "Son, there's a little Homer Simpson in all of us." /_____\
bg0l+@andrew.cmu.edu (Bruce E. Golightly) (07/05/90)
Such groups might be a good idea in some ways. There are, however, a couple of points that should be raised. There are issues of scope. A question on technique may have an answer that is not specific to an application. Discussions about "How do you...." may transend the boundries of data base managers, especially since we're moving towards standardized SQL. We also want to avoid cutting off informational requests. There are questions along the lines of "We're trying to do such-and-such. Anybody done it before?" that are not specific to any product, and the perenial "What's the best..." questions. That last question sometimes sparks interesting debates/arguments/wars about the best way to implement something. A recent data base thread involved a discussion (flame fest?) about client-server architecture that started with a reasonably innocent question as I recall. A lot of interesting and valuable points were raised. I would really hate to see the data base group drift into intellectualism or become devoted only to theoretical issues instead of the "real world". One of the reasons I read it is for the cross-fertilization that comes from getting diverse users in the same forum. ############################################################################# ! Bruce E. Golightly ! bg0l@andrew.cmu.edu (BeeGeeZeroEl) Chief of Data Base Development ! (412)268-8560 Telecommunications Group ! Carnegie Mellon University ! UCC 117, 4910 Forbes Ave. ! Pittsburgh PA 15213-3890 President, Western Penna IUA ! #############################################################################