Re: Proposed simplification of CometEvent

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:
public class ExampleCometStockStreamer implements CometProcessor {
  ...
  public class StockUpdater extends Thread {
    public void run() {
      ...
      StockUpdates[] updates = fetchUpdates();
      Client[] clients = getClients(updates);
      for (int i=0; i<clients.length; i++ ) {
        StockUpdates[] clientList = getClientUpdates(client,updates);
        client.setAndMergeNextUpdates(clientList);
        client.getEvent().callback();
      }
      ...
    }
  }
now its starting to look funny, In the trunk version of the example, I'm 
interested if the socket buffer is ready to receive data,
but the sandbox version of it simply doesn't care, it just calls for a 
tomcat thread.
sandbox:
 client.getEvent().callback(); -> no guarantee for writeability
trunk:
 client.getEvent().register(OP_WRITE) -> event fires when network buffer 
is ready to receive data.

The only thing funny here is your example. The writes done in the 
callback event are blocking if needed. For an equivalent of your code, 
you could do
if (isWriteable()) { callback(); }
etc

All of these examples are not very good, I think :( In most of these, 
you should not be using Comet I think: CPU usage will skyrocket, 
killing off the benefits over regular Servlets with blocking IO.
Of course the examples aren't very "real world'ish", the point was to 
simply show the differences in the API.

However, I think we have uncovered a larger problem than "what API do we 
pick" right now. The concept of Comet is very clear to the two of us.
I know how your impl would work, and I'm pretty sure you know how mine 
would work. But beyond that, the basics around Comet is still not well 
explained nor understood.
While we are debating method names and implementation details, our 
thread is being misunderstood.

Actually, I believe many people understand event based IO, so I don't 
see the problem. I am not debating an implementation detail or a method 
name (I would like to get good method names ideas, actually), I am 
arguing against your API design, which does not make sense to me.

I think starting to work on the Bayeux impl, or some other examples, 
will shine some more light on this.

Great, I will be able to port this impl to a reasonable API :)

Rémy


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]