RevConference - Client Server vs Stateless

[Doug Lerner]

On 1/16/04 5:25 AM, "Jerry Daniels" <mato.kola at wanblizaptan.com> wrote:

> Doug,
> 
> Sorry, for the late response on this, but, here it is...
> 
> When you say "server" to what are you referring? Web server?
> Application Server? Database server?

Something scalable and integrated, with a built-in object-oriented database.
Like Web Crossing! http://webcrossing.com. A perfect fit with Revolution, I
think!

> 
> I agree that scaled servers represent a huge performance advantage and
> WEB/APP servers are the cheapest and simplest tier to scale. I have
> built systems with over 25,000 users (with peaks of 4-5,000 concurrent
> users) and only had ONE database server (with mirroring, etc.). That
> system DID have 13 web/app servers, though. Relatively inexpensive
> boxes, I might add.
> 
> In most N-Tier systems I've used, the web servers are the only database
> users and the ones requiring authentication. The clients are not
> database users, but users of web services. This also seems that way
> most enterprise information systems are going these days. I feel like
> I've found a profitable way to fit the building of Rev thin clients
> into that mix. I just don't see that many new client-server projects
> being started in IT departments around here.
> 
> Another question: why would a server "push" to the client? Don't
> servers usually reply to a request from a client? Maybe I'm missing
> something here.

There are lots of reasons to do this:

1. Asynchronous communications. A client requests something be done at the
server side which might take time. In the meantime, it can make other
requests to the server. The server answers each request when it is done and
the client processes incoming "commands" from the server.

2. Presence and other incoming dynamic information.

The server might be updating the client as to who else is "online" or about
new incoming email or chat messages or whatever. While this can be done in a
"polling loop" that is less efficient. It is more dynamic for the server to
push information when it becomes available.

Just a couple of reasons that occur to me offhand.

doug

> 
> Best,
> 
> Jerry
> 
> On Jan 12, 2004, at 6:19 PM, Doug Lerner wrote:
> 
>> If the server has the ability to communicate with a Rev thin client
>> with
>> server push to the sockets, wouldn't direct access would be more
>> dynamic?
>> For one thing, you avoid repetitive authentications.
>> 
>> And if the server has scalable feature - like Web Crossing - you are
>> taking
>> advantage of huge server-side architecture benefits.
>> 
>> doug
>> 
>> 
>> On 1/13/04 9:09 AM, "HyperChris at aol.com" <HyperChris at aol.com> wrote:
>> 
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution