On 7/1/05, David Zülke <[EMAIL PROTECTED]> wrote:
> > Message object is cool. I'll rename it AgaviMessage (avoid stepping
> > on toes), build a constructor that'll handle 3 params by default: a
> > string (message), an integer (verbosity/log
> > level/{INFO,WARN,ERROR,DEBUG}), and another string (destination).
> > This destination will be the name of a key in the [loggers] section of
> > logging.ini (ie which logger instance to send it to).
>
> Uh oh... the destination doesn't belong there, IMO. A message shouldn't know
> where it's being logged, this is what LoggerManager::log() or whatever does,
> after all. This would be of great advantage, also for interoperability of
> messages. Think about passing one message to multiple loggers, for instance
> (although I'm an advocate of the Observer approach, as you know :p)
Right, which is the basic rift we centered on. But as you read the
rest below, it's kind of a little of both ways.
> > We came to the same conclusion you did: there's a lot of value in
> > being able to extend the Message class.
> >
> > We agreed that the Message object would be responsible for translating
> > whatever it's logging (be it an object, a string, whatever..) into a
> > string, which will then get passed along to the appropriate Logger and
> > in-turn the Appender(s).
>
> Why that? It's not flexible!? Maybe I want to "attach" data to the message
> or whatever. Translating it is no good. We should just pass the untouched
> object to the logger.
yea, I think I completely missed that part of that discussion (which
explains how 'we' agreed hehe). I -think- what he means is, you could
create a message object, perhaps in multiple steps append more data to
the message and finally have the msg object itself call the logingmgr
passing itself in so the observers could do their bidding.
$msg = new AgaviMessage();
...
$msg->append('This Happened');
...
$msg->append(' and this.. and blah..');
...
$msg->send(); // send() { LoggingMgr::log($this); }
or something..
> Yeah well but it's a different design then. We have two options:
> 1. (Bob): Tell a message or the logger manager which logger to use
> 2. (Mike/David): Broadcast messages to all loggers which themselves decide
> what to do about the message (process it; discard it).
Actually, I think both you and I are/were missing something in the
verbage. After our couple hour, sometimes heated, whiteboard
discussion today, I have a better understanding what Sean (feti) had
established and what Bob saw in it. I think his (Sean's?) made a bad
choice of words to use for what he calls 'loggers' is misleading as
it's really loggerGroups. So imagine groups of observers rather than a
bunch of observers, with there being at least a default group and
potentially some specialized groups. I was under the impression that
loggers were individual loggers. The objects registered within those
groups are what I think -we- would call loggers instead I think
they're called appenders(?).. (I still havent looked at the code).
Another distiction, which I maybe wrong about, is the observers in
this scenerio may or may not get the message object depending on
defined critera, I guess the 'logger' determines that.
I still think it's an unnecessary level of abstraction and only serves
to complicate what should be a simple facility. There was a lot of
arguments for grouping observers into different groups and being able
to specify which group to use, etc.. I still dont think I see much
merit in it, but after the discussion we had, I think Bob has the
power to make it not as annoying as it appears to be at the moment.
I've got the faith.
-Mike
PS: Bob and the other guys wont touch 'that book' because they -know-
it'll change their lives.
_______________________________________________
agavi-dev mailing list
[email protected]
http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev
