On Fri, 6 Oct 2000 11:20:38 -0400, "Brian Lloyd" <brian@digicool.com> wrote:
This is a very important point - I think people would rather be able to implement SOAP services selectively rather than by One Big Switch that may expose just about anything. I would very much like to see a project started on dev.zope.org that starts off by drafting a "user manual" that describes how SOAP services would be implemented from the standpoint of a Zope developer. This would give us a good way to come to agreement without worrying about code just yet.
Ive been considering this point of view over the weekend, and I think I disagree. Zope already has a perfectly good definition of 'web service' - the definition used by ZPublisher and the xml-rpc implementation (and FTP, to a lesser extent). Developing Zope services already involves enough detail - An extra layer of abstraction here is undesirable. I suspect many people using xml-rpc are, like me, not completely satisfied with its feature set. Id been looking to soap to fill these holes, and I would be disappointed if soap wasnt implemented in the same way.
Some attention should be given to how SOAP services get exposed by other systems at this point (they do *not* just suddenly expose every in-memory object to SOAP).
And that's plainly not the case for Petru Paler's soap implementation - he only exposes the same objects and methods exposed by ZPublisher.
There are a number of people who have recently voiced their (legitimate) concern that by default *practically everything* on their site is xml-rpc enabled
Those people were concerned that too many things were exposed via ZPublisher also.... My interpretation was that the issue is one of access control, not publishing protocol. Toby Dickenson tdickenson@geminidataloggers.com