Re: Methods, Inheritance, Exceptions, etc. (was: Re: Methods in SMIng ?)

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

Hi!

Andrea> Totally disagree on your "disagree".  People already DO "do
Andrea> what the protocol does not allow."  You do have methods today
Andrea> - they are just not obvious.  All that I would like to do is:
Andrea> 1) Make them obvious in the definition/semantics, even if not
Andrea> obvious in the protocol

I guess we are talking about `procedures' here. Let me try to give
definitions of `procedure' and `method':

A procedure is a more or less formally defined algorithm that uses
protocol operations on MIB objects to achieve a specific high-level
goal. The interface of a procedure may be formally defined by a
signature. The algorithm is executed on the manager side.

A method is a specific high-level operation on an object instance of a
class. Its interface is formally defined by a signature. The operation
is executed on the agent side where the object lives.

Andrea>                           2) If EOS or another next gen protocol
Andrea> evolves to support methods, then you do have a protocol that
Andrea> handles the semantics more cleanly.

Maybe, some time we will have a protocol that supports method
invocations. I don't say that we will never want to have methods in
SMIng. Note that issue #52 claims for language extensibility and I
support this requirement.

As far as I know, current EOS efforts are concerned with some new
specific protocol operations, but not with a new generic `invoke'
protocol operation.

Andrea> BTW, I am not arguing to introduce new constructs.  I am
Andrea> arguing to use the existing constructs of readable/writable
Andrea> attributes to map the semantics of methods.  We do have
Andrea> methods today in MIBs - for example, we request a ping and a
Andrea> traceroute in remote ops.

I know what you mean. But I would not call it methods.  So, I think we
are talking about the same thing, just using different terms.

 -frank