axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <...@us.ibm.com>
Subject Re: New Handler design - what do you think??
Date Fri, 25 May 2001 01:38:36 GMT
Still can't get to irc.  Strange, from home I usually have to
go thru a socks server "at work" to get in.  oh well.

There are a couple of blocking/gating things that just aren't
clear in your text.  I see a couple of reasons to block/gate:
 - no data yet.
   Someone before me is caching/blocking it - ie. decrypt
 - have data, can parse, but can't run

In your text you never actually say when the log handler is
told to "process", it implies that it logs them during the
"parse" step.  Well, that cause some problems.  Unless
Axis somehow knows who's going to "just" parse and who's
going to "parse" and "process" during the parse step it
can't do the "have data, can parse, but can't run" block
step avoid - in other words it can't call any handler later
in the chain.  Does that make any sense?  I'm tired.

I think there needs to be a clear rule that you can not
process during the parse step otherwise I fear that this
entire idea won't work.  If we can't rely on someone "just"
parsing then we have to block completely until all previous
handlers have parsed and run before we can "parse" the
current one.

-Dug


"Glen Daniels" <gdaniels@macromedia.com> on 05/24/2001 09:12:52 PM

Please respond to axis-dev@xml.apache.org

To:   <axis-dev@xml.apache.org>
cc:
Subject:  Re: New Handler design - what do you think??



> 1 - I can't get to irc.  I keep getting:
> -tsunami.ma.us.dal.net- *** You are not welcome on this network.
> -
> -tsunami.ma.us.dal.net- *** Autokilled for [exp/ident] Enable ident in
your
> client. Send email to exploits@dal.net with a subject of [exp/ident] for
> more details. [AKILL ID:969137152K-a] (2001/05/19 20.29)

Try /server irc.dal.net, tsunami was giving me troubles earlier too.
irc.dal.net will autosearch for any free server.

> 2 - I like it!  Couple of comments:>
> I think the text is little off:
> > 8. Manager sends events for Debug to LogHandler, then output of
> LogHandler
> >    to DebugHandler
> > 9. DebugHandler sets debug level, then tells Manager it's done (i.e.
the
> >    gating condition is satisfied and other Handlers may run).
> > 10. Manager then tells Auth Handler it can run
>
> The debug handler doesn't set the debug level 'cause you haven't
> started the 'run' phase yet.  You've mixed his parsing of the data
> with the processing of it.

I should have made this more clear.  Any Handler that isn't being held up
by
a previous gated Handler is free to process at will.  So indeed the Debug
handler does just that as soon as it's got all the data.

> In the case where you have to re-ask who wants this element only ask
> the handlers after this current one in the chain.

I'm not sure about that... have to give it some more thought.

> We still need to cache ID'd elements for href's.  Might be
> obvious, but you didn't mention it.

Definitely.

> The 'gated' stuff is a little fuzzy to me.  If one of the handlers
> is gated, shouldn't all handlers after it not even be able to
> parse anything until the gater is done?  ie. take the case where
> it's decrypting stuff.

See my last message. :)  That's not really the same as the "gated" thing.
Gating is about processing, and there's a different mechanism by which you
choose to forward events or not, I think.

--Glen





Mime
View raw message