Hi,
a couple of weeks ago there was some discussion about the skin/layer support for XML-RPC which I implemented without asking (shame on me). As some time has passed now everybody could have some fresh thoughts about it.
Let me first summarise:
* Skin and layers should be seen as typing the request.
* There are no general objections against having layers for XML-RPC.
* There are objections against using ++skin++ for XML-RPC, ++api++ would be fine.
Discussing the issue here at gocept again we've come to the following:
There are different kinds of request (BrowserRequest, XMLRPCRequest, FTPRequest, …) which depend on the “channel” or server zope is accessed through.
Then, depending on the kind of request, it often is desirable to further type the request:
* a skin for browser requests * an API for xmlrpc requests * maybe different listings or content views for webdav
We’d like to codify this understanding (the general concept of marking a request with a type) using a general IRequestType which all specific type implementations (skins, APIs, ...) are derived from. In our view this allows for understandably named implementations for each channel but still provide a common base.
Therefore we propose to:
* Create in zope.publisher.interfaces:
class IRequestType(zope.interface.interfaces.IInterface): pass
* Rename IXMLRPCSkinType to IXMLRPCAPIType(IRequestType) and create a traverser ++api++ for IXMLRPCApiType.
* Use IRequestType as new base of IBrowserSkinType (instead of IInterface).
* Do *not* provide any traverser for IRequestType since the traversers should be close to the “channel” so it is easy to understand what is happening. If the traverser name is too far fetched we end in confusion like with skin for xmlrpc.
Regards,
Hi Christian
Betreff: [Zope-dev] Request typing (to get the xmlrpc layer discussionfinished)
Hi,
a couple of weeks ago there was some discussion about the skin/layer support for XML-RPC which I implemented without asking (shame on me). As some time has passed now everybody could have some fresh thoughts about it.
Let me first summarise:
Skin and layers should be seen as typing the request.
There are no general objections against having layers for XML-RPC.
There are objections against using ++skin++ for XML-RPC,
++api++ would be fine.
[...]
I whould be very happy if we could implement the XML-RPC package as a independent server addon. I think not everyone uses XML-RPC and likes to have such a server option built-in.
What do you think can you move it to a top level package if you refactor this part.
btw, I implemented z3c.json and z3c.jsonprc. This package uses a own JSON-RPC skin type. I was choosing this additional layer implementation because I like to separate the registered methods to such requests. And we do not have the BrowserRequest at this servers at all.
We also started to implement some core server applications with only JSON-RPC APIs. There is no browser/page based UI at all installed. All is managed by JSON from another Zope server via remote (JSON-RPC) access.
If anybody likes to implement a XML-RPC API without any browser view for a server, I think it should be possible too.
Whould be great if you could take a look at z3c.jsonrpc and tell me if there is somethig to improve.
Regards Roger Ineichen
On Dec 17, 2007, at 8:22 AM, Christian Zagrodnick wrote:
Hi,
a couple of weeks ago there was some discussion about the skin/layer support for XML-RPC which I implemented without asking (shame on me). As some time has passed now everybody could have some fresh thoughts about it.
Let me first summarise:
Skin and layers should be seen as typing the request.
There are no general objections against having layers for XML-RPC.
I have a general objection for reasons of complexity. Why do we need this?
In fact, I find skins in general to introduce more complexity than they're worth.
(My $.02. This is not a veto.)
Jim
-- Jim Fulton Zope Corporation
Am 17.12.2007 um 15:40 schrieb Jim Fulton:
On Dec 17, 2007, at 8:22 AM, Christian Zagrodnick wrote:
Hi,
a couple of weeks ago there was some discussion about the skin/ layer support for XML-RPC which I implemented without asking (shame on me). As some time has passed now everybody could have some fresh thoughts about it.
Let me first summarise:
Skin and layers should be seen as typing the request.
There are no general objections against having layers for XML-RPC.
I have a general objection for reasons of complexity. Why do we need this?
About the specifics with skins for other protocols than http I can not say much.
In fact, I find skins in general to introduce more complexity than they're worth.
This baffles me somewhat. At the moment I see skins/layers as the only mechanism to let developers using an application to customize it, possibly more than once in the same instance. I find them not optimal, because they only allow customizing on the outer most level. But overrides is a failure as I understand it. I understand, that there is a trend to distinguish between "libraries" (with less zcml) and "applications" (with zcml to configure reused libraries). But on the level of applications I know of no other mechanism than layers.
So what should be used or invented instead? As a usecase take a forum application which should be installed more than once in an instance but needs different layouts and also different subset of functionality.
With regards,
__Janko
On Dec 17, 2007, at 10:07 AM, Janko Hauser wrote: ...
This baffles me somewhat. At the moment I see skins/layers as the only mechanism to let developers using an application to customize it, possibly more than once in the same instance. I find them not optimal, because they only allow customizing on the outer most level. But overrides is a failure as I understand it.
How are overrides a failure?
Skins, after all do nothing but override views.
...
So what should be used or invented instead?
I use overrides.
As a usecase take a forum application which should be installed more than once in an instance but needs different layouts and also different subset of functionality.
I don't have this use case. I wonder how many people do.
We tend to think up complex use cases and then make the zope framework more complicated to deal with them. Sometimes these are legitimate use cases, but they are rarely common cases and their solutions should generally not be inflicted on the masses.
WRT this use case, I strongly suspect it would be simpler and easier to support defining multiple configurations in ZCML and a mechanism to specify different configurations for different sites within an instance. In fact, I think Stephan Richter added this a while ago.
Jim
-- Jim Fulton Zope Corporation
Am 17.12.2007 um 16:16 schrieb Jim Fulton:
On Dec 17, 2007, at 10:07 AM, Janko Hauser wrote: ...
This baffles me somewhat. At the moment I see skins/layers as the only mechanism to let developers using an application to customize it, possibly more than once in the same instance. I find them not optimal, because they only allow customizing on the outer most level. But overrides is a failure as I understand it.
How are overrides a failure?
Perhaps I do not understand them good enough, but application developers can not use them, as there can be different applications by other developers overriding the same.
Integrators could use them to overwrite everything, but only once.
Skins, after all do nothing but override views.
Yes, but by defining a scope, which can be made location aware, during traversal.
...
So what should be used or invented instead?
I use overrides.
As a usecase take a forum application which should be installed more than once in an instance but needs different layouts and also different subset of functionality.
I don't have this use case. I wonder how many people do.
I think every multisite setup has this problem.
We tend to think up complex use cases and then make the zope framework more complicated to deal with them. Sometimes these are legitimate use cases, but they are rarely common cases and their solutions should generally not be inflicted on the masses.
WRT this use case, I strongly suspect it would be simpler and easier to support defining multiple configurations in ZCML and a mechanism to specify different configurations for different sites within an instance. In fact, I think Stephan Richter added this a while ago.
Oh that would be a new information for me, so I would be very interested, where this is implemented.
Thanks in advance
__Janko
On Dec 17, 2007 10:32 AM, Janko Hauser jh@zscout.de wrote:
Oh that would be a new information for me, so I would be very interested, where this is implemented.
z3c.baseregistry
-Fred
Am 17.12.2007 um 16:34 schrieb Fred Drake:
On Dec 17, 2007 10:32 AM, Janko Hauser jh@zscout.de wrote:
Oh that would be a new information for me, so I would be very interested, where this is implemented.
z3c.baseregistry
Uhu, thanks, this looks like it will open up many possibilities. And I'm sorry to have highjacked the original question. So back to Christians original question.
With regards,
__Janko
Hi all
Betreff: Re: [Zope-dev] Request typing (to get the xmlrpc layer discussionfinished)
On Dec 17, 2007 10:32 AM, Janko Hauser jh@zscout.de wrote:
Oh that would be a new information for me, so I would be very interested, where this is implemented.
z3c.baseregistry
Yes, that's another component which helps you protect your application from built-in backdoors.
In general I can say:
- baseregistry allows you to configure different ISite component at a global zcml level. Sites can reuse such sets of global registration in the local instance. And this registration set is not populated global at the site root.
- layers allow you to offer predefined sets of configuration ready to reuse. Without them you can only offer global configuration sets which can open backdoors.
- skins maps a set of layers to the public and make them traversable.
I allways explain it like:
Skins and layers are not needed till it comes to security. And I allways say skin and layer is the concept which allows us to separate the model and view and make the view part replacable. If you use the baseregistry it works at the local site level.
Of corse you don't need layers and skins if you develop one application and install them on one server. But if it comes to multi skins and even worse different applications on one server, we need layers and skins for security reason.
And if you don't use layers and skins, you probably can't install packages which register views at the default skin which your server is using without to open backdoors.
Layers and skins are a security concept. And a very good one.
Note, the only secure way to setup a mutli application, multi site Zope server is to use layers, sites and the baseregistry.
Everything else will make views on different apps available. And this could be a very big security problem.
Regards Roger Ineichen
On Monday 17 December 2007, Roger Ineichen wrote:
Layers and skins are a security concept. And a very good one.
Let me briefly explain what Roger refers to by the word "security" here. We consider, as I mentioned in my previous mail, the availability of views outside of our control a security risk, because someone could have done a mistake or maliciously created a security hole in a view. By controlling the contents of the layers more explicitly, we have a better idea of the views that are available.
Furthermore, skins allow us to control the permission settings of our views; overrides allow this as well, of course.
Of course, this in itself is not enough to ensure security, but I hope that tools like the one started in z3c.securitytool will eventually help us with analyzing our public views.
Regards, Stephan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
On Dec 17, 2007, at 10:07 AM, Janko Hauser wrote: ...
This baffles me somewhat. At the moment I see skins/layers as the only mechanism to let developers using an application to customize it, possibly more than once in the same instance. I find them not optimal, because they only allow customizing on the outer most level. But overrides is a failure as I understand it.
How are overrides a failure?
For one thing, they don't let you turn *off* a feature; you have to provide an alternative. Reusing naively-constructed ZCML from another package is hard enough that I've begun *copying* it into 'etc' and modifying it, rather than trying to juggle '<include>' and '<includeOverrides>'. I would still like to see the '<include>' machinery extended to support "masking" (e.g., via 'only' and 'exclude' subdirectives).
Skins, after all do nothing but override views.
Skins provide a mechanism for defining views against more specific interfaces, which is not what ZCML overrides do at all: they replace existing registrations.
So what should be used or invented instead?
I use overrides.
As a usecase take a forum application which should be installed more than once in an instance but needs different layouts and also different subset of functionality.
I don't have this use case. I wonder how many people do.
It was a common use case under CMF, and remains one in Plone.
We tend to think up complex use cases and then make the zope framework more complicated to deal with them. Sometimes these are legitimate use cases, but they are rarely common cases and their solutions should generally not be inflicted on the masses.
WRT this use case, I strongly suspect it would be simpler and easier to support defining multiple configurations in ZCML and a mechanism to specify different configurations for different sites within an instance. In fact, I think Stephan Richter added this a while ago.
Agreed. For instance, I'm finding the IRO-based lookup mechanism to be overkill for lots of applications, which basically just need a flat namespace registry (a la entry points in eggs).
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
Hi
Betreff: [Zope-dev] Re: Request typing (to get the xmlrpc layer discussionfinished)
[...]
We tend to think up complex use cases and then make the
zope framework
more complicated to deal with them. Sometimes these are legitimate use cases, but they are rarely common cases and their
solutions should
generally not be inflicted on the masses.
Configure views on layers will prevent us form backdoors if we reuse this easy installable eggs ;-)
Here is a simple sample of such a built-in backdoor:
At our fresh zope installation: http://localhost:8080/@@absolute_url
Of corse it's not this dangerous, but it shows you what I mean.
I could you show many more of such built-in backdoors on production system, but will not do this here because of security reason.
Regards Roger Ineichen
On Dec 17, 2007, at 12:39 PM, Roger Ineichen wrote:
Hi
Betreff: [Zope-dev] Re: Request typing (to get the xmlrpc layer discussionfinished)
[...]
We tend to think up complex use cases and then make the
zope framework
more complicated to deal with them. Sometimes these are legitimate use cases, but they are rarely common cases and their
solutions should
generally not be inflicted on the masses.
Configure views on layers will prevent us form backdoors if we reuse this easy installable eggs ;-)
Here is a simple sample of such a built-in backdoor:
At our fresh zope installation: http://localhost:8080/@@absolute_url
Of corse it's not this dangerous, but it shows you what I mean.
How do skins avoid this?
Jim
-- Jim Fulton Zope Corporation
HI Jim
Betreff: Re: AW: [Zope-dev] Re: Request typing (to get the xmlrpc layer discussionfinished)
[...]
Configure views on layers will prevent us form backdoors if
we reuse
this easy installable eggs ;-)
Here is a simple sample of such a built-in backdoor:
At our fresh zope installation: http://localhost:8080/@@absolute_url
Of corse it's not this dangerous, but it shows you what I mean.
How do skins avoid this?
Let me explain first how I define layer and skins.
- A layer is a configuration discriminator (request type) for traversable components.
- A named skin (configuration) makes it possible to traverse components using a context and this layer as disriminator as url path.
This means in my point of view a layer is a concept which offers a configuration namespace which somebody can use or not. If a layer has allready defined views it doesn't affect anything till we map this layer as traversable namespace. By a traversable namespace I mean the layer registered by its traversable name. Also called skin and accessible by ++skin++Name.
If we register "absolute_url" in a layer which isn't used in a skin, then this view is not available as traversable view because of the missing layer/named skin configuration.
Regards Roger Ineichen
Jim
-- Jim Fulton Zope Corporation
On Dec 18, 2007, at 5:08 AM, Roger Ineichen wrote:
HI Jim
Betreff: Re: AW: [Zope-dev] Re: Request typing (to get the xmlrpc layer discussionfinished)
[...]
Configure views on layers will prevent us form backdoors if
we reuse
this easy installable eggs ;-)
Here is a simple sample of such a built-in backdoor:
At our fresh zope installation: http://localhost:8080/@@absolute_url
Of corse it's not this dangerous, but it shows you what I mean.
How do skins avoid this?
Let me explain first how I define layer and skins.
- A layer is a configuration discriminator (request type)
for traversable components.
- A named skin (configuration) makes it possible to traverse
components using a context and this layer as disriminator as url path.
This means in my point of view a layer is a concept which offers a configuration namespace which somebody can use or not. If a layer has allready defined views it doesn't affect anything till we map this layer as traversable namespace. By a traversable namespace I mean the layer registered by its traversable name. Also called skin and accessible by ++skin++Name.
If we register "absolute_url" in a layer which isn't used in a skin, then this view is not available as traversable view because of the missing layer/named skin configuration.
Which does nothing to "protect" you from components registered for the default layer or for IBrowserRequest.
Jim
-- Jim Fulton Zope Corporation
On Tuesday 18 December 2007, Jim Fulton wrote:
If we register "absolute_url" in a layer which isn't used in a skin, then this view is not available as traversable view because of the missing layer/named skin configuration.
Which does nothing to "protect" you from components registered for the default layer or for IBrowserRequest.
Yes, because in our code we never ever expose the registrations in the default layer. We consider that layer hostile. :-) (Eventually we hope to rid ourselves from even importing any configuration that registers into the browser layer, but the Zoep packages need some refactoring to do this in a sane way.)
IBrowserRequest is a big problem, since it is the base interface for all layers. I used to scan the ZCML for components registered for IBrowserRequest. I have not done this in a while, but should make it a habit again. I hope that security analysis tools, such as z3c.securitytool will eventually help us identify those problems.
Regards, Stephan
On Monday 17 December 2007, Jim Fulton wrote:
WRT this use case, I strongly suspect it would be simpler and easier to support defining multiple configurations in ZCML and a mechanism to specify different configurations for different sites within an instance. In fact, I think Stephan Richter added this a while ago.
Yes, see z3c.baseregistry. Base registries effectively allow "skinning" of all components registered with the component registries. This includes adapters and utilities. I sometimes call base registries a way to do site-based component skinning. :-)
However, see my other responses (when written ;-) on why skins are still useful.
Regards, Stephan
On Monday 17 December 2007, Jim Fulton wrote:
As a usecase take a forum application which should be installed more than once in an instance but needs different layouts and also different subset of functionality.
I don't have this use case. I wonder how many people do.
I certainly do have this use case all the time. :-) We often have to write a publically facing and an admin UI. The admin UI should not be available publically. With skins this can be solved very elegantly.
In a bigger project, we have a true hosted services environment, where customers want very customized UIs, both in look and feel. In those cases skinning is very important to us, since we can choose which layer we have to use as bases for the custom skin.
We tend to think up complex use cases and then make the zope framework more complicated to deal with them. Sometimes these are legitimate use cases, but they are rarely common cases and their solutions should generally not be inflicted on the masses.
I think that using default browser layer is the way for people not to worry about skins. However, I have found that this is a really bad long-term solution.
The biggest problem is that I do not have any control over the default browser layer. I install a package to use its API, but often get a lot of views for the default browser layer as well. Without careful review, there is now way for me to tell whether this opens a security hole. It is thus much safer, to start a new skin from scratch, and carefully add registrations. We developed some minimal base skins (see z3c.layer), which do the most basic setup and which we reviewed somewhat for security.
And even if the the security is okay, I would not want to expose all the views. I want control, but often, registering everything from scratch is very tedious. Layers -- and thus skins -- act as collection s of view registrations. I think that z3c.form* demonstrates this very nicely. If I only use the IFormLayer, I only get the widgets, and only by inheriting from IDivFormLayer or ITableFormLayer, I also get form layout components.
As Jim pointed out in another E-mail, base component registries (such as z3c.baseregistry) can solve this problem, but only partially. Base registries can only be applied on the site-level. So sure, I can customize the look and feel (and much more) for every site. But for skinning I often want multiple UIs for the *same* site. This problem cannot be solved with base registries today without writing additional software. And this use case is extremely important to us!
Regards, Stephan
On Dec 17, 2007 8:22 AM, Christian Zagrodnick cz@gocept.com wrote:
There are different kinds of request (BrowserRequest, XMLRPCRequest, FTPRequest, …) which depend on the "channel" or server zope is accessed through.
We have this use case:
The server is accessed through a number of different channels, each associated with some URL re-writing. This includes in most cases a ++skin++<name> path element, often with additional path elements. The skin used is associated with the channel.
We have a couple of different cases where there are XML-RPC methdods that should be associated with the channel as well. Using anything other than ++skin++ seems like silliness in this case: we need something that can associate the request with a channel, regardless of the type of the request (XML-RPC, browser, etc.).
We don't care that ++skin++ is the name of the request-typing path element, but we do want a single path element that can mark the request regardless of the request type. Preferably without re-architecting our applications.
-Fred
On Monday 17 December 2007, Christian Zagrodnick wrote:
a couple of weeks ago there was some discussion about the skin/layer support for XML-RPC which I implemented without asking (shame on me). As some time has passed now everybody could have some fresh thoughts about it.
Since the original implementation and discussion, I had a lot more time to discuss this proposal with Roger (who was heavily in favor of it), think about it, and work on other HTTP-based protocols.
Thus, I am now in favor of a solution. It is good that you laid out the implementation details as well.
Let me first summarise:
- Skin and layers should be seen as typing the request.
Well, that's what they actually do.
- There are no general objections against having layers for XML-RPC.
I think there were pretty strong objections to layers for XML-RPC and all other non-browser HTTP requests.
- There are objections against using ++skin++ for XML-RPC, ++api++
would be fine.
I think I was against anything typing non-browser related.
Therefore we propose to:
- Create in zope.publisher.interfaces:
class IRequestType(zope.interface.interfaces.IInterface): pass
This is good.
- Rename IXMLRPCSkinType to IXMLRPCAPIType(IRequestType) and create a
traverser ++api++ for IXMLRPCApiType.
This would not fulfill the use case that Fred brought up in his response to the proposal. I really like his points and his historical considerations.
I think, it would be ideal to have one way to specify the request type, maybe through ++type++. If, for legacy reasons, ++skin++ is easier to use, then that's fine with me too.
Let's widen our considerations to JSON and REST as well.
What do others think?
- Use IRequestType as new base of IBrowserSkinType (instead of IInterface).
Okay.
- Do *not* provide any traverser for IRequestType since the traversers
should be close to the “channel†so it is easy to understand what is happening. If the traverser name is too far fetched we end in confusion like with skin for xmlrpc.
Right, this is very important. The same rule should apply for IBrowserRequest; see the other discussion thread of this mail.
Regards, Stephan
On 2007-12-18 17:32:01 +0100, Stephan Richter srichter@cosmos.phy.tufts.edu said:
On Monday 17 December 2007, Christian Zagrodnick wrote:
a couple of weeks ago there was some discussion about the skin/layer support for XML-RPC which I implemented without asking (shame on me). As some time has passed now everybody could have some fresh thoughts about it.
Since the original implementation and discussion, I had a lot more time to
discuss this proposal with Roger (who was heavily in favor of it), think about it, and work on other HTTP-based protocols.
Thus, I am now in favor of a solution. It is good that you laid out the implementation details as well.
Let me first summarise:
- Skin and layers should be seen as typing the request.
Well, that's what they actually do.
- There are no general objections against having layers for XML-RPC.
I think there were pretty strong objections to layers for XML-RPC and all other non-browser HTTP requests.
Yes there*were. I had the impression that once it got clear what it means everybody was sort of fine.
- There are objections against using ++skin++ for XML-RPC, ++api++
would be fine.
I think I was against anything typing non-browser related.
Therefore we propose to:
- Create in zope.publisher.interfaces:
class IRequestType(zope.interface.interfaces.IInterface): pass
This is good.
- Rename IXMLRPCSkinType to IXMLRPCAPIType(IRequestType) and create a
traverser ++api++ for IXMLRPCApiType.
This would not fulfill the use case that Fred brought up in his response to
the proposal. I really like his points and his historical considerations.
I think, it would be ideal to have one way to specify the request type, may be through ++type++. If, for legacy reasons, ++skin++ is easier to use, then that's fine with me too.
Yes. ++skin++ for XML-RPC is actually in the 3.4 branch already. So it's not easy to just remove it.
Let's widen our considerations to JSON and REST as well.
Would it be possible to detect a JSON vs. normal HTTP request like it happens with XML-RPC?
What do others think?
Yes, what do others think? It's quite hard for me to do anything because the discussion is kind of nebulous.
- Use IRequestType as new base of IBrowserSkinType (instead of IInterface
).
Okay.
- Do *not* provide any traverser for IRequestType since the traversers
should be close to the “channelâ€
so it is easy to understand what is
happening. If the traverser name is too far fetched we end in confusion like with skin for xmlrpc.
Right, this is very important. The same rule should apply for IBrowserReque st; see the other discussion thread of this mail.
Hey,
Am Freitag, den 21.12.2007, 09:58 +0100 schrieb Christian Zagrodnick:
Yes, what do others think? It's quite hard for me to do anything because the discussion is kind of nebulous.
We have different to topics that need discussion/decision:
a) There is breakage in publisher eggs for which the XML-RPC stuff assumed to be the reason. I'll figure out what's going on there today so that the immediate breakage goes away.
b) We intended to remove the functionality this week as it was not agreed on to include. However, we (gocept) found that it was already released in the 3.4 series as we (gocept) let the topic slip for too long. This means we can't just take it out again. We (gocept) 're honestly sorry this happened. How shall we proceed?
c) There is a need for a general solution regarding the issue of providing a `request typing` mechanism for various protocols (including sub-protocols of HTTP). Skins are one implementation, the XML-RPC skinning is another implementation. For this we should start writing a proposal that can be discussed. It's getting hard to follow what the goals, steps, risks and their assessments/counter measures are. Writing a proposal and adjusting it over time would be best here.
Christian
Hi,
Am Freitag, den 21.12.2007, 10:28 +0100 schrieb Christian Theune:
We have different to topics that need discussion/decision:
a) There is breakage in publisher eggs for which the XML-RPC stuff assumed to be the reason. I'll figure out what's going on there today so that the immediate breakage goes away.
Update: I looked at this and the issue is not the XML-RPC stuff, but installing an egg with the correct extra to let the tests get all required dependencies for testing.
b) We intended to remove the functionality this week as it was not agreed on to include. However, we (gocept) found that it was already released in the 3.4 series as we (gocept) let the topic slip for too long. This means we can't just take it out again. We (gocept) 're honestly sorry this happened. How shall we proceed?
I was wrong, the XML-RPC features went into the trunk (3.5) only. I'll move those changes to a branch that we (gocept) can continue to use for now and clean up the trunk from our changes.
Christian
Hi,
Am Freitag, den 21.12.2007, 10:28 +0100 schrieb Christian Theune:
b) We intended to remove the functionality this week as it was not agreed on to include. However, we (gocept) found that it was already released in the 3.4 series as we (gocept) let the topic slip for too long. This means we can't just take it out again. We (gocept) 're honestly sorry this happened. How shall we proceed?
I have removed the XML-RPC layer support by backing out the related changes from zope.publisher, zope.app.publisher and zope.traversing.
zope.app.publisher and zope.traversing had alpha releases. I superseded those by making another alpha release.
The up-to-date packages in PyPI now neither provide nor require a package with the XML-RPC skin support.
zope.publisher did not have a released version including the XML-RPC skin support yet, so I ommitted making a release here.
I created branches `3.5-gocept-xmlrpc-skin` of the affected packages so our existing projects can keep using those in the short term until we find another solution.
Christian
Hey,
Christian Zagrodnick wrote:
a couple of weeks ago there was some discussion about the skin/layer support for XML-RPC which I implemented without asking (shame on me). As some time has passed now everybody could have some fresh thoughts about it.
Let me first summarise:
Skin and layers should be seen as typing the request.
There are no general objections against having layers for XML-RPC.
There are objections against using ++skin++ for XML-RPC, ++api++ would
be fine.
I don't really have time to read this whole discussion, but note that Grok's REST support uses ++rest++<protocolname> and then provides a rest layer (for that protocol) to the request. That sounds quite similar to what you are proposing for XMLRPC.
It's still ugly as POST and GET need to be handled by something else than PUT and DELETE, unfortunately; you can't use a different publisher (publication? whatever the name is for this handle) for GET and POST as the interface isn't set at the point it kicks in.
Regards,
Martijn
I don't really have time to read this whole discussion, but note that Grok's REST support uses ++rest++<protocolname> and then provides a rest layer (for that protocol) to the request. That sounds quite similar to what you are proposing for XMLRPC.
It's still ugly as POST and GET need to be handled by something else than PUT and DELETE, unfortunately; you can't use a different publisher (publication? whatever the name is for this handle) for GET and POST as the interface isn't set at the point it kicks in.
Regards,
Martijn
In SchoolTool we used to start another server for REST to have a different Publication for REST calls. As now I have started using Paste to start up schooltool, and paste does not support 2 Zope3 servers running on different ports using the same WSGI application (at least i don't know how to do that in paste.ini) I have opted for a brute force solution - URL based dispatch in the SchoolToolWSGIApplication code that switches between publications and request types before Zope3 has a chance to pick the wrong set.
So instead of 2 servers for both applications now i have 1 WSGI server, and a weird kind of midleware that selects the right application (while both applications share the component registry and ZODB). I kind of like it that way, I could even give the freedom for the user to select the REST url prefix that he likes/wants to have, just like he could configure the port of the REST server.
Ignas
Hey,
Ignas Mikalajunas wrote: [REST in Grok]
In SchoolTool we used to start another server for REST to have a different Publication for REST calls. As now I have started using Paste to start up schooltool, and paste does not support 2 Zope3 servers running on different ports using the same WSGI application (at least i don't know how to do that in paste.ini) I have opted for a brute force solution - URL based dispatch in the SchoolToolWSGIApplication code that switches between publications and request types before Zope3 has a chance to pick the wrong set.
So instead of 2 servers for both applications now i have 1 WSGI server, and a weird kind of midleware that selects the right application (while both applications share the component registry and ZODB). I kind of like it that way, I could even give the freedom for the user to select the REST url prefix that he likes/wants to have, just like he could configure the port of the REST server.
In Grok there's no WSGI setup necessary to do REST. I like it that way at present. Perhaps the WSGI route will start to make more sense once that matures significantly. Grok will do its bit to help mature the WSGI way, but until then I'm not convinced your approach is the easiest way? It sounds like quite a bit of additional setup is required compared to just writing REST views.
Regards,
Martijn
On Thursday 20 December 2007, Ignas Mikalajunas wrote:
In SchoolTool we used to start another server for REST to have a different Publication for REST calls.
I like that approach best too. I decided to use it in z3c.rest. A custom publication object allows you to implement an API that makes most sense for a RESTive API. I am still playing around to see what the best API is though.
Regards, Stephan
I also have zero opinion about this but I'll note as the dedicated whiner, that, delta some policy change, until this gets worked out, the Cheese Shop is broken for people who want to install zope.app* packages (and other related packages). A release of zope.traversing has a dependency on another release that doesn't exist in the index. Somebody made the decision to keep it as-is until this issue gets worked out. It has been broken now for roughly two and a half weeks.
- C
On Dec 20, 2007, at 5:13 AM, Martijn Faassen wrote:
Hey,
Christian Zagrodnick wrote:
a couple of weeks ago there was some discussion about the skin/ layer support for XML-RPC which I implemented without asking (shame on me). As some time has passed now everybody could have some fresh thoughts about it. Let me first summarise:
- Skin and layers should be seen as typing the request.
- There are no general objections against having layers for XML-RPC.
- There are objections against using ++skin++ for XML-RPC, ++api++
would be fine.
I don't really have time to read this whole discussion, but note that Grok's REST support uses ++rest++<protocolname> and then provides a rest layer (for that protocol) to the request. That sounds quite similar to what you are proposing for XMLRPC.
It's still ugly as POST and GET need to be handled by something else than PUT and DELETE, unfortunately; you can't use a different publisher (publication? whatever the name is for this handle) for GET and POST as the interface isn't set at the point it kicks in.
Regards,
Martijn
Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Good job! :)
I agree that this is really annoying.
Really, this needs to get unscrewed. I'm skeptical that this is "released in 3.4" since a dependency on an unreleased alpha egg is involved.
Jim
On Dec 21, 2007, at 12:32 PM, Chris McDonough wrote:
I also have zero opinion about this but I'll note as the dedicated whiner, that, delta some policy change, until this gets worked out, the Cheese Shop is broken for people who want to install zope.app* packages (and other related packages). A release of zope.traversing has a dependency on another release that doesn't exist in the index. Somebody made the decision to keep it as-is until this issue gets worked out. It has been broken now for roughly two and a half weeks.
- C
On Dec 20, 2007, at 5:13 AM, Martijn Faassen wrote:
Hey,
Christian Zagrodnick wrote:
a couple of weeks ago there was some discussion about the skin/ layer support for XML-RPC which I implemented without asking (shame on me). As some time has passed now everybody could have some fresh thoughts about it. Let me first summarise:
- Skin and layers should be seen as typing the request.
- There are no general objections against having layers for XML-RPC.
- There are objections against using ++skin++ for XML-RPC, ++api++
would be fine.
I don't really have time to read this whole discussion, but note that Grok's REST support uses ++rest++<protocolname> and then provides a rest layer (for that protocol) to the request. That sounds quite similar to what you are proposing for XMLRPC.
It's still ugly as POST and GET need to be handled by something else than PUT and DELETE, unfortunately; you can't use a different publisher (publication? whatever the name is for this handle) for GET and POST as the interface isn't set at the point it kicks in.
Regards,
Martijn
Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists -http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-- Jim Fulton Zope Corporation
Am Freitag, den 21.12.2007, 12:39 -0500 schrieb Jim Fulton:
Good job! :)
I agree that this is really annoying.
Really, this needs to get unscrewed. I'm skeptical that this is "released in 3.4" since a dependency on an unreleased alpha egg is involved.
It turns out that there are separate issues around. This breakage does not relate to the XML-RPC `skin` traversal, see my other post.
Christian
Hey,
Am Freitag, den 21.12.2007, 12:32 -0500 schrieb Chris McDonough:
I also have zero opinion about this but I'll note as the dedicated whiner, that, delta some policy change, until this gets worked out, the Cheese Shop is broken for people who want to install zope.app* packages (and other related packages). A release of zope.traversing has a dependency on another release that doesn't exist in the index. Somebody made the decision to keep it as-is until this issue gets worked out. It has been broken now for roughly two and a half weeks.
Thanks for saying the name of the broken package. See my other post. I'll work on it tomorrow, depending on the surrounding conditions that might hinder me to actually resolve it.
Christian
Hi,
Am Freitag, den 21.12.2007, 12:32 -0500 schrieb Chris McDonough:
I also have zero opinion about this but I'll note as the dedicated whiner, that, delta some policy change, until this gets worked out, the Cheese Shop is broken for people who want to install zope.app* packages (and other related packages). A release of zope.traversing has a dependency on another release that doesn't exist in the index. Somebody made the decision to keep it as-is until this issue gets worked out. It has been broken now for roughly two and a half weeks.
I've looked at the situation. The package isn't broken, but the test suite is badly structured regarding extras.
Thomas tried to get rid of the zope.app* dependency of zope.traversing by making the import of the application controller optional.
However, the one test that assures this feature is always run without checking whether zope.app.applicationcontrol is available.
zope.app.applicationcontrol is required by the 'test' extra.
If you install the zope.traversing egg with the `test` extra enabled you will see the tests run. If you leave the `test` extra out you will see breakage.
Looking at the various tracebacks I get when not using the test extra I assume that some of the failures aren't even related to this particular change.
In general: if you want to run the tests, install the egg with the `test[s]` extra.
So far for the analysis of the current situation of the package.
Christian
-
Chris McDonough -
Christian Theune -
Christian Zagrodnick -
Fred Drake -
Ignas Mikalajunas -
Janko Hauser -
Jim Fulton -
Martijn Faassen -
Roger Ineichen -
Stephan Richter -
Tres Seaver