NewLC - Active Object in the lights of Client-Server framework - Comments

Re: Active Object in the lights of Client-Server framework

gangs — Fri, 12 Sep 2008 07:56:27 +0200

Although this article is good for visualizing the use of active object with client server framework. Essentially it does not mean that this is how active objects should be used.
1. First, active objects are essentially for handling asynchronous requests. This should not be obviously linked to a client server framework just because most of them are asynchronous.
2. Servers are not only where active object should be used, it all depends on the design of the server. Usually we create server to isolate certain operations from the user's process space, handle multiple client requests, prevent spoofing(protected servers). So, the decision of creating a client server and that too asynchronous is purely a design decision.
Basically in the light of this article the strength of active object should not be mis-interpreted/diluted. Active objects give us the beautiful notion of issuing asynchronous request and a framework to perform the completion neatly (RunL).

gangs.

Re: Active Object in the lights of Client-Server framework

somenath — Wed, 13 Aug 2008 20:53:17 +0200

Thats what I tried to explain. Actually I found it difficult understanding it through the timer example which are commonly given in books. Those examples hardly decipher the basic idea behind the Active Object framework.. Anyway, your explanation is very good. Hopefully this discussion will be able to remove the haziness that is there around active objects.

Re: Active Object in the lights of Client-Server framework

alh — Wed, 13 Aug 2008 11:08:32 +0200

Active Objects gets so much easier to understand when you forget about the strange wide spread idea that they have anything at all to do with threads, or in any way or form is a replacement for them.

What they are is implementing event driven programming.

An active object is nothing more then an event observer, that performs some kind of task on the receiving of an event.

Now let me tell you how this is possible in an Windows application. Once I had developed one such application using the Windows asynchronous I/O pattern and windows event mechanism. There the task of reading of the data from the communication port was delegated to a background thread. The background thread used to read the data and when it finishes some specific amount it used to fire an event to the front end UI, which then rendered the data in the front end UI.

And this is exactly how it works in symbian too.
The only difference really is that there is already an OS service available that implements that "background thread", you don't have to implement it yourself.
All you have to do is to create an active object that listnes for the "data available" event, after issuing a request to the server thread to read some data.

Active Object in the lights of Client-Server framework

somenath — Wed, 13 Aug 2008 10:00:35 +0200

When I started understanding Active Object framework in Symbian, it was difficult for me to grasp the idea how the front end UI is not frozen, in the event of long running task, even when we don't use multiple threads. But when i started understanding the active object framework in conjunction with the client-server architecture of symbian, I got the idea. I would like to share it with you.