W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: [ietf-dav-versioning] <none>

From: Jim Amsden <jamsden@us.ibm.com>
Date: Tue, 19 Jun 2001 15:08:29 -0400
To: ietf-dav-versioning@w3.org
Message-ID: <OF1925F62A.57E4E421-ON85256A70.006814D5@raleigh.ibm.com>
Geoff says:
Encapsulation is preventing you from seeing the implementation.  That
is exactly what an IETF protocol does ... you can only see and use the
public parts (which are the methods and properties defined by the
protocol).  A public property is as much a part of the type signature
as a public method.  All we are saying is that we should be using type
signature equivalence, rather than type name equivalence, since HTTP
does not provide a "subtype declaration" mechanism, but the versioning
protocol has defined a type signature exposure mechanism
(DAV:supported-method-set and DAV:supported-live-property-set).

Encapsulation can also be used to suppress detail and provide higher level 
abstractions to reduce complexity for some client classes. I agree a 
protocol does present an encapsulation of a server's services in a 
standard way. What we're talking about here is encapsulating the details 
of the protocol itself - we're up a meta-level. HTTP doesn't provide a 
subtype declaration mechanism, but WebDAV does - DAV:resourcetype. I think 
some of us would just like to be able to use it to hide the details and 
name the things in the protocol the way we name them in the specification. 
This, ideally, shouldn't have to be discovered through introspection as it 
requires the introspector to know protocol details that might better be 
handled by the server. Its a many-to-one thing for complexity management. 
You have one server doing the work instead of many clients.
Received on Tuesday, 19 June 2001 15:08:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT