REQUEST FOR DISCUSSION (RFD)
               unmoderated group comp.lang.c++.rad.misc
             unmoderated group comp.lang.c++.rad.power++

This is a formal Request For Discussion (RFD) for the creation of the
world-wide unmoderated Usenet newsgroups comp.lang.c++.rad.misc and
comp.lang.c++.rad.power++.

This is not a Call For Vote (CFV); you cannot vote at this time.
Procedural details are below.

Newsgroup lines:
comp.lang.c++.rad.misc  Miscellaneous discussion of C++ RAD development.
comp.lang.c++.rad.power++       Programming with Powersoft Power++.

RATIONALE: all groups

Rapid Application Development (RAD) is a growing trend in the
programming community. More and more we are seeing developers of
traditional programming environments create in addition to their more
traditional products, products which promote the use of Rapid
Application Development principles and models.

Because of the growing use of Rapid Application Development
environments in the C++ community, it is becoming of increasing value
to have a forum for the discussion of the principles and models of
Rapid Application Development with C++ as the base language.

RATIONALE: comp.lang.c++.rad.misc

Much of C++ Rapid Application Development is proprietary to the
environment one uses.  C++ Rapid Application Development is
component-centric in nature. Because of this many of the discussions
will be specific to the environment the programmer is using.  The
discussion of general, non-environment specific Rapid Application
Development it's principles, models and advocacy require it's own
forum.

RATIONALE: comp.lang.c++.rad.power++

Power++ is a C++ language Rapid Application Development environment
with an unique component-centric interface. Power++ is the product of
Powersoft, the creators of Watcom C++, PowerBuilder, Sybase SQL
Anywhere, etc. Power++ was formerly known as Optima++.

Power++ incorporates and integrates many of the features of the other
Powersoft family of products into the Power++ environment. The
patented DataWindow, Sybase's SQL Anywhere, Watcom C++ compiler. This
close integration with the other Powersoft/Sybase/Watcom products and
the unique component-centric development environment make the
discussion specific to Power++ and of little relevance to users of
other C++ environments.

There is an Power++ mailing list called OptimaPP.  It has over 400
subscribers and receives 25-50 messages per day and growing. There
have been numerous request about and for an Power++ newsgroup on both
the mailing list and also in the comp.lang.* newsgroups especially
comp.lang.c++.

OptimaPP is a mailing list for users and potential users of Power++ to
discuss the use of Power++. Any Power++ relevant discussion is
encouraged.

To subscribe to OptimaPP:
In the body of the message add the line:
SUBSCRIBE OptimaPP [Your real name]
and send to:
Mail-Ser...@earthchannel.com

CHARTER: all groups

The normal practice should be that most articles are posted to one
single, correct group ONLY.  Cross-posting is only appropriate when
the problem is hard to categorize or when it legitimately concerns
more than one group.  Answers should be posted to a single group only
once the nature of the problem has been ascertained. Many articles of
this sort should go to comp.lang.c++.rad.misc (only).

Advertising Policy:

Following standard Usenet guidelines, the newsgroup is not intended to
be used for commercial advertising, solicitation, or marketing of
products or services. However, announcements of products or services
directly relevant to the newsgroup will be permitted, but only in the
following circumstances:

-The product is new or has undergone substantial change
-The posting is clearly marked as an announcement by prefixing the subject
line with the tag, "ANNOUNCE:"
-The posting is brief and contains no marketing hype.

Binaries:

Binaries are not allowed in the comp.lang.c++.rad.* groups.  If a
binary is appropriate to your message, post the binary to one of the
appropriate binary groups, www or ftp site and add a line to your
message as to where the binary may be retrieved.

Source Code:

Much of the discussion involved in the comp.lang.c++.rad.* newsgroups
will involve source code. It is appropriate to post a reasonable
amount of source code in your messages. Do not post an excessively
large piece of source code. If you have a large piece of source code
that you would like to make available to the group, post the source
code to an appropriate www or ftp site.

END CHARTER.

CHARTER: comp.lang.c++.rad.misc

This newsgroup provides an open forum for the discussion of general
non-environment specific C++ Rapid Application Development issues.

Advocacy:

Advocacy discussions may be posted here.  Articles supporting or
criticizing RAD C++, for discussion of its position in the
marketplace, the future potential of RAD C++ and all other issues that
are primarily opinions about RAD C++.

Environment specific questions should be posted to the
comp.lang.c++.rad.* group appropriate to that environment. If such a
group does not exist, the question may be posted here.

This is not a group for general C++ discussion. Please post general
C++ questions to comp.lang.c++.

END CHARTER.

CHARTER: comp.lang.c++.rad.power++

This newsgroup provides an open forum to discuss issues pertaining to
Power++. Postings related to all aspects of Power++ would be welcome.
These postings would range from: discussions of the Power++
development environment, Windows application development using
Power++, integrating Power++ with PowerBuilder, Power++ and the
DataWindow, Power++ and Sybase SQL Anywhere, ActiveX, OCX, OLE,
Relational Databases.

In short any posting related to Power++ would be entertained.  Advice
and support would especially be encouraged.  This is an unmoderated
newsgroup, with no official standing to any particular company.

END CHARTER.

PROCEDURE:

This is a request for discussion, not a call for votes. In this phase
of the process, any potential problems with the proposed newsgroup
should be raised and resolved. The discussion period will continue for
a minimum of 21 days (starting from when the first RFD for this
proposal is posted to news.announce.newgroups), after which a Call for
Votes (CFV) may be posted by a neutral vote taker if the discussion
warrants it. Please do not attempt to vote until this happens.

All discussion of this proposal should be posted to news.groups.

The RFD attempts to comply fully with the Usenet newsgroup creation
guidelines outlined in "How to Create A New Usenet Newsgroup" and "How
to Format and Submit a New Group Proposal." Please refer to these
documents (available in news.announce.newgroups) if you have any
questions about the process.

DISTRIBUTION:

This RFD has been posted to the following newsgroups:
news.announce.newgroups,news.groups,comp.lang.c++,comp.soft-sys.powerbuilder
,comp.database.sysbase,comp.database.oracle,comp.lang.pascal.delphi.misc,com
p.os.ms-windows.programmer.misc

After it has been posted to news.announce.newgroups it will be reposted to:
comp.lang.c++.moderated, comp.os.ms-windows.programmer.tools.misc,
comp.os.ms-windows.programmer.win32,

and the following mailing list:
OptimaPP mailing list

Proponent: Jimmie Houchin <jhouc...@texoma.net>
Mentor: Jonathan Grobe <gr...@netins.net>

I've seen posts here telling Optima++ (now called Power++) advocates
to get their own newsgroup. Here's an opportunity to help do just
that.

The RFD I am trying to pass is for a new hierarchy.
comp.lang.c++.rad.*

I do not know if anyone has submitted an RFD for a newsgroup for C++
Builder or not. If there has been no formal RFD for a C++ Builder
group, then now is a good opportunity to create one by adding a new
group to the comp.lang.c++.rad.* hierarchy.

If anyone would like to help be a proponent for such and create a
RATIONALE: and CHARTER: for the new group, just e-mail me.

I would even write the RATIONALE and CHARTER if I knew the C++ Builder
community would want to join in on this RFD.

Any changes as such would appear on a 2nd RFD.

I posted this message only to the Delphi group. All other discussion
pertaining to the RFD should occur in news.groups.

Let me know.

Thanks,

Jimmie Houchin

Hi Andy,

I have already submitted a 2nd RFD which will included Borland and
C++Builder in the group hierarchy.

I have not received any reply from my submission as of yet. Hopefully
it will appear soon.

When creating this group I was not knowledgable of issues concerning
using the comp.lang groups for the base of the hierarchy. Others
brought up the use of the term RAD. The direction of my 2nd RFD is
this:

comp.rapid-app-dev.misc
comp.rapid-app-dev.borland.misc
comp.rapid-app-dev.borland.c++builder
comp.rapid-app-dev.powersoft.misc
comp.rapid-app-dev.powersoft.power++

This is not official yet, as the submission of the 2nd RFD has not yet
been posted.

My goal in the new name was for clarity of the group hierarchy while
maintaining reasonableness of size. Hopefully this name is acceptable
and accomplishes both.

A Delphi group would fit in well with this hierarchy and RFD. However
as you stated their are already well established Delphi groups. Their
participation in the borland.misc group would be accepted and
appreciated as it is for the discussion of non-language specific IDE
isssues.

When looking at the soft-sys groups it appeared to me that most were
mathmatical, statistical and scientific in orientation. The only
notable difference I remember are the appbuilder and powerbuilder
groups.

Let me know what you think.

Jimmie Houchin
proponent

What exactly would go in .borland.misc, and why wouldn't it also go in
.c++builder?

If people are programming with the same VCL under both Pascal and C++,
then into which newsgroup could they post? ...c++builder? something else?

I personally think that, since all our development effort is targetted at
Windows, it would be much more natural to have
  comp.os.ms-windows.programmer.tools.vcl

(to go in addition to the ...tools.owl, ...tools.mfc &c).

We could even have ...vcl.writing, ...vcl.using

--
Lucian Wischik, Queens' College, Cambridge CB3 9ET. ljw1...@cam.ac.uk

People wanting to know how to extend a component in C++Builder want
their explanation in C++. People who want to know how to extend a
component in Delphi want their explanantion in Pascal. The question
should be directed to the group most appropriate and only that group.

The group specific to this RFD are only the initial groups. There is
great possibility for others. How about the coming wave of Rapid
Application Development tools for Java. Assymetrix's Supercede,
Symantec's Visual Cafe, VIBE, etc. What about RAD products for other
platforms Mac, OS/2, Linux, Unix, etc.

To place these IDE based development tools in a platform specific
hierarchy would be to either scatter them throughout comp.* groups or
to limit them completely.

How about comp.sys.mac.programmer.codewarrior? Once a Macintosh only
programming environment, it nows is a development platform for
Macintosh, Windows 95/NT, Be, Playstation, etc. It has long outgrown
its hierarchical name.

This is simply the first RFD to establish some newsgroups for Rapid
Application Development tools. Rapid Application Development is not
limited to any one vendor, platform or language and the newsgroup
hierarchy which is created to serve the users of these tools should
not be either.

Thank you for your questions and allowing me to clarify the situation.
When the 2nd RFD is posted you may read the RATIONALE: and we can
discuss it further if need be.

Jimmie Houchin
proponent

In article <334f8ced.76413...@news.texoma.com>,

I feel that someone actively participating in comp.lang.c++ (?) would
more naturally seek out comp.lang.c++.builder.misc rather than
seek out an entirely different hierarchy. And if he does find
comp.rapid-app-dev.* he might not be fortunate enough to locate
the already existing Delphi groups under comp.lang.pascal.delphi.*.

Delphi is based on Object Pascal and has it's own set of
language extensions. Thereby justifying it's presence under the
comp.lang.pascal hierarchy. IMO a similar case can be made for
C++ Builder as well.

After all, if a user searches for "C++", he might end his search
in the comp.lang.c++ hierarchy...

--
=\
 *=- R.Moberg, CD-Player Pro info @ http://home.sn.no/home/mobergru
=/

 +---- mober...@oslonett.no wrote (14 Apr 1997 19:43:54 +0200):
 | In article <334f8ced.76413...@news.texoma.com>,
 | jhouc...@texoma.com (Jimmie Houchin) wrote:
 | >comp.rapid-app-dev.misc
 | >comp.rapid-app-dev.borland.misc
 | >comp.rapid-app-dev.borland.c++builder
 | >comp.rapid-app-dev.powersoft.misc
 | >comp.rapid-app-dev.powersoft.power++
 | [snip]
 | >A Delphi group would fit in well with this hierarchy and RFD. However
 | >as you stated their are already well established Delphi groups. Their
 | >participation in the borland.misc group would be accepted and
 | >appreciated as it is for the discussion of non-language specific IDE
 | >isssues.
 |
 | I think this undermines the entire comp.lang.* hierarchy.

I have made a habit of disagreeing with that viewpoint.

The .lang. portion of a newsgroup name, especially when that
close to the beginning of the name, should carry a lot of
weight when it comes to expected content.  All too often
discussions that have little to do with a given language, and
much to do with the quirks of development on a particular
platform, become off topic for a .lang. newsgroup.

In my opinion of course.  If the recent comp.lang.java.* reorg
is any indication; it is a minority opinion.

 | I feel that someone actively participating in comp.lang.c++ (?) would
 | more naturally seek out comp.lang.c++.builder.misc rather than
 | seek out an entirely different hierarchy.
 +----

There are platform specific newsgroups that have split from
comp.lang.c++.  I believe this benefits both sets of readers.
People interested in a platform have a rich resource and people
interested in a language have a rich resource, their paths
crossing _when necessary_.

When a language isn't popular on a number of platforms I can
see why the line may not be as clear.  So now I have a habit.

--
Gary Johnson     gjohn...@season.com
Privacy on the net is still illegal.

But why have 'rapid-app-dev'? How about just
  comp.rad.*

I also think that component issues are sufficiently cross-platform between
Pascal and C++ that we should have comp.rad.borland.components.*
I disagree with your suggestion that people would be interested in having
answers about components in their own particular language. In my
experience, they're not. The C++Builder forum at Borland is full of bits
of Pascal. And there are chunks of C++ here in
comp.lang.pascal.delphi.misc.

--
Lucian Wischik, Queens' College, Cambridge CB3 9ET. ljw1...@cam.ac.uk

As stated in a previous post many of these IDEs are multilingual.
Grouping by IDE and vendor allows for non language discussion which
would be of benefit to users of the other products of the same IDE to
partake in the discussion.

As far as someone looking for lets say C++Builder in the comp.lang.c++
groups all one need to do is ask in comp.lang.c++ and any number of
users will be able to provide the answer. It may even be possible to
get such info in the comp.lang.c++ FAQ.

Also with c++builder being in the name of the group a simple "search"
(find type search) in the groups list will provide the newsgroup.

The RFD is broad and hopefully many of the coming Rapid Application
Development tools will feel welcome to join such a group hierarchy.
My goal is a simple one. To navigate this RFD to  a successful
completion. The name to me is only an means to an end.

The original RFD as you can see was for a comp.lang.c++.rad.*
hierarchy. Discussion occurred on many fronts which led me to offer a
new group hierarchy such as comp.rapid-app-dev.*. This avoids both
appending the comp.lang.* hierarchy with vendor and IDE specific
groups and also gives a clearer understanding of the groups intent by
avoiding the use of acronyms such as RAD.

Hope this helps all understand where we are at this current stage of
discussion.

Hopefully the 2nd RFD will be released soon.

Jimmie Houchin
proponent

Thanks for your reply.

I will reply to this message in the thread for the 2nd RFD.

Please move all discussion to the new RFD.

2nd RFD: comp.rapid-app-dev.*

Hope to see you there.

Jimmie Houchin
proponent