On Thu, Jun 21, 2001 at 05:06:51PM -0400, [EMAIL PROTECTED] wrote:
> I don't think POE has much of this. I would like to get a list of all
> current sessions (probably a list of IDs), then query for, with aliases
> and current states. Something like :
>
> @ids=$kernel->session_list();
> @events=$kernel->session_evnets($ids[0]);
> @aliases=$kernel->alias_list($ids[0]); # does this currently work?
what shall i say, use an object layer :))
i agree to Rocco that events should be kept private, though POE doesn't
have different privacy levels for methods (session event handlers)
another big plus for the object layer are big applications.
with the above, you would get a big, flatted out list. the bigger it gets
the harder it is to read and use, even for humans. if you use associations
instead of one-sided references, they are structured. you know which object
still wants to talk to another one and keeps it alive.
with aliases sessions can declare themselves to support a specific service
by supplying a reference to themselves under a specific name. but those
server objects decide, when it stops serving. if an application has a lot
of services that depend on each other, maintaining session lifetimes is
a lot of work for developers.
it should be better for client sessions to acquire a postback or something
like that for a service(-session). then GC could be used to determine
session lifetimes.
of course using an object layer would recquire setting up associations
explicitly. i guess there are some people who rather just send the event
to an alias and don't like this approach. but there is almost no work for
well designed applications. all the others (including quick hack scripts)
could use standard poe calls.
i know that such an object layer is not really hard to design. and that a lot
of things need to be done to really use its possibilities.
but it would be worth the effort.
torvald
