Do we need to give up the capability for external integration in order to simplify the implementation of service contracts?
If we want to support plug-ins we want to be able to arbitrarily drop in something external or something written as a set of Tcl procs without the caller knowing the difference. Today we only directly support direct calls to PL/[pg]SQL or Tcl but in the future might want to support SOAP calls directly, for instance.
I don't really see service contracts themselves as being cumbersome, just their implementation and the lack of documentation.
Hmmm...it looks like Til's suggestion gives up the capability to directly call PL/[pl]SQL directly. This is one of the advantages of the current service contract mechanism - the caller/spec writer doesn't need to know what language particular implementations are written in.
Also ... service contracts are somewhat pervasively used at the moment, so we can't just get rid of them (fear the wrath of Tom Jackson :)
I see you talk about determining whether or not something's implemented for a particular OBJECT TYPE above. I don't see service contracts as being the proper mechanism for defining object type methods. We don't have a "proper mechanism" and we probably should and using namespaces such as you describe (which is similar to how datatypes in the form builder are defined) would be a way to do it. Objects are special within OpenACS and I have no problem treating them as being special. Service Contracts are extremely general by design, being a way to map specs and bindings whether or not an implementation is part of OpenACS or, for that matter, running on the same server.
I'll try to think about this stuff and look at it some more when my head's a bit clearer (I've just arrived from Berlin and am very tired).
