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.. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements
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 :( Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
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
Okay, has anything been done at all?
Where would I start? What's left to do?
Petru Paler contributed some preliminary work: http://classic.zope.org:8080/Collector/1360/view While I think that this is a good thing and I'm glad he did it, I think that experience has shown that just suddenly making *everything* available via a new protocol (xml-rpc, SOAP) is not really the right approach. 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 - and they have no easy way to turn it off or make things selectively available. 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. 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). We should also anticipate some of the work being done in "discoverability" of SOAP services in our draft (which I think will affect how you go about "defining" a Web service. Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
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
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.) You can hack some of it with clever SiteAccess usage but it is a hard problem. Ideally, you'd also want anything that deals with the above to be related to user roles as well. This is because the thing which makes the problem hard is that something like standard_html_header wants to be editable by Managers TTW, which means it also has to be visible TTW. However, it's probably not something you want exposed to anonymous users, especially as a TTW enitity in its own right. objectIds is my other favourite example ;-) What do other peiople think? What would be the overhead of introducing the above type of publishign restrictions? cheers, Chris
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.
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
How about listing what products they're used by/defined in? That could be incredibly useful for me :-) cheers, Chris
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
Michel Pelletier wrote:
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.
I dunno, I'd prefer to see something like: Role | Manager |\/| (dropdown list ;-) DTML Method [] Add [] View ...etc... Squishdot Site [] Add [] View [] Moderate ...etc... rather than the current list where you can have something like: Use [] [] [] ...where someone has carelessly named a permission and you have no idea what product it relates to. cheers, Chris
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
On Thu, Oct 05, 2000 at 01:25:44PM -0700, Michel Pelletier wrote:
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.
Glad to see that people finally show some interest in that :) That patch was the result of a long night, but I'm sure it can be gotten to work properly (right now I think it has problems with exception handling). -- Petru Paler, mailto:ppetru@ppetru.net http://www.ppetru.net - ICQ: 41817235
participants (7)
-
Brad Clements -
Brian Lloyd -
Chris Withers -
Michael Bernstein -
Michel Pelletier -
Petru Paler -
Toby Dickenson