Re: Finalised Glossary Definitions

Mark Jones wrote:

> Here's the distinction I am drawing.  Fundamentally, a particular
> handler is code.  It has inputs (blocks) and outputs (blocks
> to add to the message or return from the message, side effects
> on the world).  People seem to roughly agree on that.
>
> A handler is passed some block(s), may cause some side-effects in the
> world, may contribute some new blocks to the message, etc.
> A handle signature is something like:  handler (in blocks, ...).
>
> From the handler definition, you can't infer that handler1 should get
> blocks of type A and handler2 should get blocks of type B.

Ah, yes! but this is precisely why, in my opinion, we should be targetting handlers, not
processors or nodes. The actor attribute (or the <namespace:tag>, if we follow that
route), would be used for that purpose.

> You can't infer that handler1 and handler2 are related, or that handler1 should be run
> before handler2.  Where does this knowledge live?

In a block? (As least this is why I have heard on the list before, I think.) But again
this takes us back to the late-binding vs. static-binding discussion.

> I think of a "module" as being the locus of the knowledge that ties together related
> syntactic features (blocks) and behavior (handlers).
>
> So my notion of module encompasses:
> (1) a set of related handlers
> (2) a set of related block definitions
> (3) an understanding of the relationships among the items in (1) and (2)

I think you are also implicitely suggesting:
(4) an concrete, machine executable representation of these relationships

which is where I think you differ from the glossary.

> When a module is added to a processor, it brings with it the behavior
> (handlers), the mapping between blocks and handlers, execution constraints,
> etc.  It is a modeling and implementation issue as to whether
>  (a) this knowledge is simply absorbed into the processor's own global
>      structures and the notion of a module practically ceases to exist
>      at run-time, or
>  (b) the processor algorithms actively incorporate a module API
>      which keeps the knowledge encapsulated
>
> (a) seems to be the SOAP approach.

I think there are merits to both approaches, and I am not sure where I stand anylonger.
:)

> By the way, it seems to me that a module must encompass both the
> knowledge about how to CONSTRUCT an appropriate message (or parts
> therein) as well as how to INTERPRET those parts on the receiver side.

The INTERPRETer being the Handler, and the CONSTRUCTor being a (yet) unnamed thing (a
"Builder"?).

> We've tended to ignore the constructive side, but there must be some
> API for the sender which takes a relatively high-level
> characterization of the required behavior and manufactures the
> appropriate blocks.  This API should be modular so that independent
> blocks can be inserted and targeted independently, while still
> permitting any necessary dependencies (e.g., ordering).

I can see Henrik frowning his eyes... :)  But yes, seriously, there will need  to be an
API

> I think it is clear that the concepts of module and handler are
> distinct and both useful.  Particular conventions tend to cloud up the
> distinction in simple cases.  For example, if there is a convention
> that fixes the relationship between an element tag and the name of a
> handler, then the mapping between blocks and handlers becomes trivial
> and can be hardwired into the processor.  If, furthermore, there is
> only one handler per module, then it makes "module" and "handler" seem
> interchangeable since there is a 1-1 relationship and there aren't any
> constraints among handlers to worry about.

Jean-Jacques.

Received on Wednesday, 21 March 2001 09:45:34 UTC