[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Methods, data hiding, and friends



Hi

This comparison is interesting and I have a different but additional view on this: I see the capabilities more in a package perspective. It is really similar to Linux packages since some capabilities need other capabilities. At some point, it should be possible to draw a dependences graph (or requirements graph). For example, #validate capability requires the #candidate capability. Or if I develop an #xupdate capability, I should have the #xpath capability. Also, when Netconf will have different releases of some capabilities, it will be good to have such description of the requirements (requires #xpath>=1.1).

As a consequence for hello exchange, this aspect could be used in two ways:
- discover capabilities inconsistencies (this entity advertises #validate but not #candidate => problem) - only advertise the last levels of dependence (this entity advertises #validate so it supports #candidate for sure)

I think it is up to the capability developer to decide which parts of the API can be public and which must remain private. Anyway, in general, it might be very complicated to prevent a developer from using such method or external methods calls.

Regards,
Vincent


Phil Shafer a écrit :
"David Harrington" writes:
In SNMP, the small number of functions have direct access to any
variable anywhere in the MIB (scoped by a copntext of course). This is
very consistent with the apporoch used by assembly language, BASIC
(before structured BASIC was developed), C, and other procedural
languages.

This might be true if libc had only three functions (get, get-net, set).
Seen in this light, SNMP is more like early basics, where one could
peek and poke, based on the documentation, but never had a proper API.

In O-O development, the software industry found a need to have things
like inheritance, private methods, and friend methods.

And factories and overloading and interfaces and virtual functions
and templates and generics and other sources of endless training
courses (in popular vacation sites ;^)

In netconf, a capability's method such as "create-vlan" may need to
manipulate the data elements of other capabilities, such as the
interface capability. Will methods of one capability be permitted to
directly modify the data of another capability, or will they be
constrained to utilize public and friend interface methods of the
other capabilities?

I see netconf as more like C, but that's probably because I like C.

A capability is like a library, with the functions as RPC methods
and the documentation as, well, documentation.  With a little IDL
work, one can make the functions appear as real RPCs to a C program,
so that "ping(host, size, timeout)" does the right thing.  (I admit
I had an easier time doing this in perl, with associative array
arguments and AUTOLOAD, but it works in C too.)

Thanks,
 Phil

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>