Okay, has anything been done at all? Where would I start? What's left to do? Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements

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

Chris Withers wrote:

Toby Dickenson wrote:

...

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.

I think the issue is that you can't limit the visibility of objects right now. You can limit their access easily enough (or more tortuously if you don't want people to access the bits of a page on their own (standard_*,etc) via a complex web of proxy roles and required permissions) but there doesn't appear to be any easy way to say "right, I want this object exposed for reading and writing via FTP and reading via HTTP, while this one shouldn't be URL traversable but I'd like to edit it via WebDAV and this method is for use via XML-RPC but really shouldn't be visible anywhere else.)

It seems like this can be handled rather well by simply adding a 'XML-RPC access', a 'SOAP access' and a 'WebDAV access' set of permissions. we already have a 'FTP access' permission which works fine. Thse could then be matched with appropriate 'view' permissions as well. On a slightly different note, I think that the permissions list should be viewable in two more ways: A view where permissions are grouped into 'subjects', (for example all the ones I just mentioned should go into a 'access protocol' subject and possibly a 'view protocol' subject) and another view where permissions are grouped according to the roles that have them. These different views should all be on the same tab, with hyperlinks to switch between them (sort of like the 'local roles' screen is linked from 'security'). Michael Bernstein.

Chris Withers wrote:

Michael Bernstein wrote:

...

On a slightly different note, I think that the permissions list should be viewable in two more ways: A view where permissions are grouped into 'subjects', (for example all

Perhaps a better idea is that Permissions are classes that inherit from super class permissions, so permission could be laid out in a heirarchical fasion. Permission Add Add Foos Edit Edit Bars Delete Delete Bobs View etc... we've thought about this before. implementation makes my brain hurt. -Michel

Brian Lloyd wrote:

...

MS has released ROPE for client-side SOAP development (finally).

I can't seem to find anything in Zope for doing SOAP, but it was announced in Dec 1999 as "upcoming".

What is the status of SOAP on Zope, I need to know if I can use ROPE..

Hi Brad -

SOAP is still something we want to do, but it is on hold right now (we just don't have the resources at the moment). I've been hoping that someone might take the lead and start a project on dev.zope.org, but so far that hasn't happened :(

Take a look at: http://classic.zope.org:8080/Collector/1360/view I remember glancing at it for a bit, it might be a good start to at least get it to the same level of support as xml-rpc. -Michel