[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [koi-dev] Logging all events for later replay...

mike:

        (my apologies for the delayed response)

At 03:02 PM 4/2/2003, Michael R Head wrote:
I'm in a PhD program at Brandeis studying how to build same
time/different place collaborative groupware
[http://group.cs.brandeis.edu/~group/].

        Interesting looking stuff. I'm glad you're interested in Koi as a vehicle for working with it in Eclipse. By the way, which of the recent papers would you suggest as a must read?

My problem: the methodology we have developed requires that every action
be logged so we (when putting on our HCI/discourse analyst hats) can
replay and examine how the collaborators... well... collaborate, so we
can refine the interface.

how would koi support this for the network packets?

I'd really like (for starters) to be able to build a simple chat plugin
that logs all data (probably at the server) for later replay. This is
probably easy on the face of it, but if there's any core support
planned, I'd love to hear about it, or possibly nudge development in
that direction ;-)

        At the moment Koi doesn't support that (or actually any) sort of logging. It would be very easy to add it on the client side. Take a look at org.eclipse.koi.client.ServiceStub. Every client request will pass thru either ServiceStub.invoke() or ServiceStub.invokeWithException(). They would be the natural place to put your action logging..

        You could then create a Logging Service to record the client requests on the server, storing requests from all clients in the same database. The would probably simplify your analysis.

        Logging the requests on the client side may be all you need. But if you need to log requests as they come in to the server, well...

        Logging actions is not so simple on the server side. Koi is designed to be able to use a variety of RPC mechanisms but at the moment the only one available is the Apache XML-RPC implementation. It's a fairly efficient implementation. Part of that efficiency comes from the way it directly maps client requests to handler classes on the server. Unfortunately this means that there's no direct way to intercept those requests. Hence all logging code would have to be part of the server code handling the requests. If you're writing all of the server-side service code this may not be a problem. On the other hand logging the client requests may provide you with all the data you need.

        I took a look at the Insectivore project. Pretty neat. It seems like fitting that into the Koi framework would give you an active server to do analysis with. The kind of analysis a project manager would love to get her hands on. 80)

to'c

---
Consider the master's description
of awakened existence, how seemingly simple:
Hungry, I eat; sleepy, I sleep.
Is this choosing completely, or not at all?

In either case, everything seem to conspire against it.
                                        - Jane Hirshfield