«

In article <dq->,
jebblue <> wrote:

> On Sat, 10 Nov 2012 13:23:41 -0800, Kevin McMurtrie wrote:
>
> > In article <k7ln1q$id0$>,
> > "sl@exabyte" <> wrote:
> >
> >> I have been reading the above topics for several days, and now utterly
> >> confused.
> >>
> >> I am trying to to put a server program for char room feature on my web
> >> site. To make the server program more efficient I am thinking of using
> >> sockets.
> >>
> >> For the client end, I would to use socket if I can (otherwise AJAX).
> >>
> >> At the server end, PHP or java daemon.
> >>
> >> My questions:
> >>
> >> 1.
> >> a) For the front end, can I use java servlet ? I understand that websocket
> >> is not generally supported.
> >> b) Is java servlet supported by browsers generally ?
> >>
> >> 2.
> >> I discover that there are comet, long polling, websocket. I am very
> >> confused
> >> now.
> >>
> >> Can some experts discuss somewhat of all these options ?
> >>
> >> Thanks.
> >
> >
> > I'm using WebSockets with Jetty. It generally works well for two-way
> > text messaging and it doesn't interfere with REST/Servlet APIs. Recent
> > but important features, like ping/pong and different message types,
> > aren't supported by browsers. There's also zero error handling defined
> > so you'll need to work that in.
> >
> > Tomcat has experimental support for WebSockets but I recommend Jetty
> > instead.
>
> Jetty doesn't even have a clean start/stop CLI interface like
> Tomcat has had all along. Tomcat is the basis for all major
> Enterprise Java web servers.

Why the totally off-topic reply about the start/stop procedure?

/opt/jetty/bin/jetty.sh stop
/opt/jetty/bin/jetty.sh start

Or use the init.d scripts. That looks a lot like Tomcat.

I recommend using the server best supports the features you need.
Software developers aren't paid lots of money to make decisions based on
FUD. There's good reason for Restlet, Jetty, Resin, Tomcat, and other
engines existing.
--
I will not see posts from Google because I must filter them as spam

On 11/23/2012 06:26 PM, jebblue wrote:
> On Sat, 10 Nov 2012 13:23:41 -0800, Kevin McMurtrie wrote:
>
>> In article <k7ln1q$id0$>,
>> "sl@exabyte" <> wrote:
>>
>>> I have been reading the above topics for several days, and now utterly
>>> confused.
>>>
>>> I am trying to to put a server program for char room feature on my web
>>> site. To make the server program more efficient I am thinking of using
>>> sockets.
>>>
>>> For the client end, I would to use socket if I can (otherwise AJAX).
>>>
>>> At the server end, PHP or java daemon.
>>>
>>> My questions:
>>>
>>> 1.
>>> a) For the front end, can I use java servlet ? I understand that websocket
>>> is not generally supported.
>>> b) Is java servlet supported by browsers generally ?
>>>
>>> 2.
>>> I discover that there are comet, long polling, websocket. I am very confused
>>> now.
>>>
>>> Can some experts discuss somewhat of all these options ?
>>>
>>> Thanks.
>>
>>
>> I'm using WebSockets with Jetty. It generally works well for two-way
>> text messaging and it doesn't interfere with REST/Servlet APIs. Recent
>> but important features, like ping/pong and different message types,
>> aren't supported by browsers. There's also zero error handling defined
>> so you'll need to work that in.
>>
>> Tomcat has experimental support for WebSockets but I recommend Jetty
>> instead.
>
> Jetty doesn't even have a clean start/stop CLI interface like
> Tomcat has had all along. Tomcat is the basis for all major
> Enterprise Java web servers.
>

That is utter nonsense.

On 12/07/2012 02:09 AM, jebblue wrote:
> On Wed, 28 Nov 2012 21:02:59 -0800, Kevin McMurtrie wrote:
>
[ SNIP ]
>
>> I recommend using the server best supports the features you need.
>> Software developers aren't paid lots of money to make decisions based on
>> FUD. There's good reason for Restlet, Jetty, Resin, Tomcat, and other
>> engines existing.
>
> FUD? Nope. Mistake yes, FUD no, not at all. When WebSphere or
> WebLogic decide to switch to Jetty I'll look at it again.
>
I'm with Kevin on this one. And bear in mind, when you say "WebSphere"
or "WebLogic" it's not like you've got this dedicated team of web
container experts, with each app server development staff, that
constantly evaluates servlet containers and gets their decisions quickly
acted upon.

In practice the resources allocated for software development on a major
JEE app server are less than you might think. Most are probably either
fixing bugs or designing/implementing new features (which latter is
driven by the marketers). If an included/embedded web/servlet container
is cutting it, and that original choice probably came down to one or a
small handful of people way back when (so why do they know more than
you, exactly?), and the cost of *change* is probably not justifiable for
incremental improvements achieved by using another container, why do you
think that what a major app server uses gives you any major guidance at all?

Other than that what they use is good for them. It's possibly not the
_best_ for them at any given time. It's very possibly not the best
choice for anyone else's requirements, although you can expect it to be
adequate.

AHS

On Fri, 23 Nov 2012 11:26:14 -0600, jebblue <> wrote, quoted or
indirectly quoted someone who said :

>>> b) Is java servlet supported by browsers generally ?

Servlets run on the Server. To the browser client they just look like
static web pages. You can run some intelligence such as Ajax, Applets
or JWS at the client. Then you can send any message format you want
back and forth.

see http://mindprod.com/jgloss/servletwomb.html

For very high speed communication, you use UDP packets. The catch is,
there is no guaranteed delivery. But often that may not matter if all
you are doing is apprising each other of current state.

See http://mindprod.com/jgloss/udp.html
--
Roedy Green Canadian Mind Products http://mindprod.com
Students who hire or con others to do their homework are as foolish
as couch potatoes who hire others to go to the gym for them.

On 11/23/2012 12:26 PM, jebblue wrote:
> On Sat, 10 Nov 2012 13:23:41 -0800, Kevin McMurtrie wrote:
>> I'm using WebSockets with Jetty. It generally works well for two-way
>> text messaging and it doesn't interfere with REST/Servlet APIs. Recent
>> but important features, like ping/pong and different message types,
>> aren't supported by browsers. There's also zero error handling defined
>> so you'll need to work that in.
>>
>> Tomcat has experimental support for WebSockets but I recommend Jetty
>> instead.
>
> Jetty doesn't even have a clean start/stop CLI interface like
> Tomcat has had all along.

No.

Jetty comes with CLI script to start/stop.

> Tomcat is the basis for all major
> Enterprise Java web servers.

No.

WebSphere and WebLogic come with own.

JBoss uses Tomcat and Glassfish uses a modified Tomcat.

Arne

On 12/7/2012 1:09 AM, jebblue wrote:
> On Wed, 28 Nov 2012 21:02:59 -0800, Kevin McMurtrie wrote:
>> /opt/jetty/bin/jetty.sh stop
>> /opt/jetty/bin/jetty.sh start
>>
>> Or use the init.d scripts. That looks a lot like Tomcat.
>>
>
> Thanks, guess I didn't look far enough.

Given that it is in the same location as for Tomcat, then
it appears that you have not been looking at all.

> Tomcat is still the basis of
> every major enterprise Java platform.

Still not.

>> I recommend using the server best supports the features you need.
>> Software developers aren't paid lots of money to make decisions based on
>> FUD. There's good reason for Restlet, Jetty, Resin, Tomcat, and other
>> engines existing.
>
> FUD? Nope. Mistake yes, FUD no, not at all. When WebSphere or
> WebLogic decide to switch to Jetty I'll look at it again.

They probably prefer their own.

But heard of a small company called Google?

They use Jetty!

Arne

On 11/10/2012 11:21 AM, sl@exabyte wrote:
>> However, look at Java applets:
>> <http://docs.oracle.com/javase/tutorial/deployment/applet/>
>>
>> All GUI browsers on Mac, Linux and Windows that I know of support Java
>> applets. Android doesn't: use an app. iOS doesn't: use their
>> ecosystem.
>
> My apology, 'java servlet' should be 'java applet'.

That is a bloody big difference.

> I think coding in java applet allows access to sockets.

It does.

Server side is more tricky.

Either a standalone server/daemon program or a full
Java EE application-server with a JCA inbound adapter.

And you need to get through all the firewalls, which may
be easy or may be impossible.

Arne

On 11/11/2012 8:37 AM, sl@exabyte wrote:
> Just thinking. If javascript can communicate with java applet (which can
> access sockets), why bother to have websocket ?
>
> Forgive me if this is a stupid question.

Actually it is a pretty good question.

Java applets are out of fashion - JavaScript is in fashion.

There are or will soon be 1 billion smartphones with browsers
without applet support.

A Java-JavaScript solution is more complex than a pure
JavaScript solution.

But that said, then I still consider the Java applet
solution to be a perfectly viable solution that must be
considered.

Arne