Re: Split group?
Chris Smith wrote:
Arne Vajh?j <firstname.lastname@example.org> wrote:
There are not that many ME questions are there ?
I see enough. YMMV.
On the other hand there are a lot of server side stuff
postings, which is also rather uninteresting for those not
I ultimately agree, but I can see room for argument. I find it
difficult, sometimes, to distinguish between "server side" questions and
regular Java questions. For example, the thread about using TCP and
UDP; probably not a "server side" thread, but it's pretty questionable.
Jakarta HttpClient? Could be used on either server or client side; I
use it more on the server side, but your experience could be different.
Network broadcast: again, it depends. There are a number of questions
about web services that could apply to either the server or client
sides. Most XML APIs start in Java EE and migrate their way to SE.
JNDI is actually an SE technology, where it is used for things like LDAP
and DNS lookup; but it's overwhelmingly more likely to be used in an app
server. Where should these threads go?
comp.lang.java.netapps or something of the sort. All of the ones that
deal with client/server pairs, server-side programming, or just about
anything else except generally-applicable basic programming in Java,
standalone desktop applications, and (maybe) applets (that don't have
any fancy connection with server-side software -- so, games and
animations and suchlike for Web pages, rather than front ends/clients
for Web applications).
I worry that creating too many groups (along with the inevitable
netcopping when someone posts to a group that someone else considers
wrong) will discourage discussion more than encourage it.
Then worry, because the server I'm currently using has a couple dozen
comp.lang.java.foo groups, most of which look to be unused or
thinly-populated. We probably only need three or four programming ones:
this one, the proposed web-apps one (which can subsume the existing
database and beans ones), the proposed mobile one, and maybe keep
comp.lang.java.gui separate (though I see a fair amount of gui stuff
here in c.l.j.p ...). Throw in .advocacy, .general, and
..installing-and-using or whatever, and you've also covered the needs of
nonprogrammers who bump into a Java problem of some sort.
> It isn't a
clean division, and there's a lot of cross-over interest. We shouldn't
forget that people can still just not read the threads that they don't
True, which suggests an alternative: establish a subject tag convention,
e.g. [beans], [server], [mobile] or [micro], ... to make configuring
subject filters easy. (Mind you, you can abuse your existing bayesian
spam filter, if your news client has one, to chuck everything with "ejb"
or even "swing" and "JFrame" ...)
That said, though, the volume of messages convinces me that a server
side group would be a good idea. If only we could guarantee the absence
of multiposters and netcops, then it'd be an easy choice; but alas, that
doesn't appear likely to happen soon.
The "server-side" group should cover both ends of web-application
deployments, not just the server-side. Most of the
non-general-purpose-programming questions I see here involve web
applications of some kind, but about half are client-side and involve
communicating with the server, rather than the other way around. The
next biggest batch are candidates for comp.lang.java.gui, and then micro
edition stuff. (That's after ignoring "who's the bigger idiot" and other
non-Java-related topics, which seem to land somewhere between
comp.lang.java.gui and client-server stuff in frequency, though that
frequency looks to have spiked and then declined lately, so I can't be
sure what's representative of the norm. Obviously none of that stuff
belongs in comp.* at all though.)