RFC: ZTK custom publications, zope.app.publication, and zope.traversing
I'm trying to make the Zope Toolkit (ZTK) publisher/publication framework a little easier to deal with. I think zope.app.publication mostly provides a generally useful publication implementation. It has 2 problems: - Its getApplication method digs a particular object out of a ZODB database. Some people would like the flexibility of not using ZODB. - It aggressively proxies objects using zope.security.checker.ProxyFactory. Some people don't want to use proxies and those that do might want to use a different proxy or checker implementation. It was already possible for a subclass to override getApplication fairly cleanly. (This also entailed overridding __init__ in a pretty simple way.) I made it possible to override proxying by overriding the proxy method. At this point, I think zope.app.publication provides a pretty reasonable base class for custom publication implementations, although the module arrangement could be made a bit simpler. In working on this, I've found the implementation and tests of zope.app.publication to be split between zope.app.publication and zope.traversing. I want to sort this out, but I'm not certain what the intent if zope.traversing is. I think the intent has become muddled over time, if it was ever clear in the first place. :) Early on, we mixed up ZPT path traversal and URL traversal. These are similar, but different. There are features you want in ZPT traversal, like the resource namespace that you don't want in URL traversal. Similarly, you want features like virtual host support and default pages in URL traversal but not in ZPT traversal. Early on, we used path traversal in many places, not just ZPT, which is probably why most of the code in zope.traversing isn't in zope ZPT- related package. Early on, we decided that the menu framework should be able to filter menu items based on whether the user could traverse to an item. On some level, this was reasonable because it made menu specifications simpler, but it adds great expense and complexity. I'm not sure anyone in the know uses the menu framework anymore. If they are and aren't specifying permissions on their menu items, they are being helped to do the wrong thing. Originally, zope.app.publication defined a base class, PublicationTraverse, that provided traverseName. Even though I may have done this, I don't know why this was broken out into a separate base class. I don't think anyone else is subclassing this, but I don't know. I propose the following: In phase 1 reduce the scope of zope.traversing: - Move path traversal code to zope.tales - Move the URL traversal code used by zope.app.publisher.menu to zope.app.publisher.menu. Refactor it to use the request.publication. Deprecate definition of menu items without permissions. - Move the virtual host and skin tests from zope.traversing to zope.app.publication. The only things left, I think will be the namespace framework and the absolute-url support. (Both of these could use more thought, but I've used up my thinking budget for this morning. :) In phase 2, simplify the class tree in zope.app.publication Merge zopepublication, http, browser, and xmlrpc. traverse using request.method when request,method isn't one of GET, HEAD, or POST. Maybe in phase 3: - Create zope.publication from zope.app.publcatiobn - use webtest rather than zope.app.testing. - Maybe provide a paste deployment mechanism for easily assembling publisher-based appls based on prototype work I'm doing in zc.publication. Thoughts? Jim -- Jim Fulton Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
I'm trying to make the Zope Toolkit (ZTK) publisher/publication framework a little easier to deal with. I think zope.app.publication mostly provides a generally useful publication implementation. It has 2 problems:
- Its getApplication method digs a particular object out of a ZODB database. Some people would like the flexibility of not using ZODB.
- It aggressively proxies objects using zope.security.checker.ProxyFactory. Some people don't want to use proxies and those that do might want to use a different proxy or checker implementation.
It was already possible for a subclass to override getApplication fairly cleanly. (This also entailed overridding __init__ in a pretty simple way.)
I made it possible to override proxying by overriding the proxy method. At this point, I think zope.app.publication provides a pretty reasonable base class for custom publication implementations, although the module arrangement could be made a bit simpler.
In working on this, I've found the implementation and tests of zope.app.publication to be split between zope.app.publication and zope.traversing. I want to sort this out, but I'm not certain what the intent if zope.traversing is. I think the intent has become muddled over time, if it was ever clear in the first place. :)
Early on, we mixed up ZPT path traversal and URL traversal. These are similar, but different. There are features you want in ZPT traversal, like the resource namespace that you don't want in URL traversal. Similarly, you want features like virtual host support and default pages in URL traversal but not in ZPT traversal.
Early on, we used path traversal in many places, not just ZPT, which is probably why most of the code in zope.traversing isn't in zope ZPT- related package.
Early on, we decided that the menu framework should be able to filter menu items based on whether the user could traverse to an item. On some level, this was reasonable because it made menu specifications simpler, but it adds great expense and complexity. I'm not sure anyone in the know uses the menu framework anymore. If they are and aren't specifying permissions on their menu items, they are being helped to do the wrong thing.
Originally, zope.app.publication defined a base class, PublicationTraverse, that provided traverseName. Even though I may have done this, I don't know why this was broken out into a separate base class. I don't think anyone else is subclassing this, but I don't know.
I propose the following:
In phase 1 reduce the scope of zope.traversing:
- Move path traversal code to zope.tales
- Move the URL traversal code used by zope.app.publisher.menu to zope.app.publisher.menu. Refactor it to use the request.publication. Deprecate definition of menu items without permissions.
- Move the virtual host and skin tests from zope.traversing to zope.app.publication.
The only things left, I think will be the namespace framework and the absolute-url support. (Both of these could use more thought, but I've used up my thinking budget for this morning. :)
In phase 2, simplify the class tree in zope.app.publication
Merge zopepublication, http, browser, and xmlrpc. traverse using request.method when request,method isn't one of GET, HEAD, or POST.
Maybe in phase 3:
- Create zope.publication from zope.app.publcatiobn - use webtest rather than zope.app.testing. - Maybe provide a paste deployment mechanism for easily assembling publisher-based appls based on prototype work I'm doing in zc.publication.
Thoughts?
+1. I would also like to be able to break the current zope.app.publication dependencies within Zope2: - ZPublisher.BaseRequest uses zope.app.publication for the EndRequestEvent class - Products.Five.compuonent likewise uses it for 'IBeginReqeustEvent', 'IEndRequestEvent', and 'BeforeTraverseEvent' Can we move those events and their interfaces out into a non-zope.app package? E.g., the as-yet-notional zope.publication package you mention for phase 3? Or zope.traversing? There are dependendencies on zope.app.publisher as well: - Products.Five.browser.adding uses 'getMenu'. - Products.Five.browser's configure.zcm uses IMenuItemType, MenuAccessView, and IMenuAccessView. - Products.Five.form.metaconfigure uses menuItemDirective. - Produts.Five.viewlet.metaconfigure uses viewmeta. - Products.Five.fivedirectives uses IBasicResourceInformation. The first two may be the only real uses of the menu framework you discuss above. I would actually like to move Products.Five.viewlet out into a separate pacakge (five.viewlet), as I don't think there is a core requirement to support the viewlet machinery. The last one is trickier: that interface likely belongs somewhere like zope.browser. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKPm6s+gerLs4ltQ4RAhNMAJ9g2hxeFOQPrzKlqA97PWLWbALwoQCfeOVy CqGt2HPjW3AlJMlmu1n0dhM= =iqvU -----END PGP SIGNATURE-----
On Jun 21, 2009, at 1:32 PM, Tres Seaver wrote: ...
Thoughts?
+1. I would also like to be able to break the current zope.app.publication dependencies within Zope2:
- ZPublisher.BaseRequest uses zope.app.publication for the EndRequestEvent class
- Products.Five.compuonent likewise uses it for 'IBeginReqeustEvent', 'IEndRequestEvent', and 'BeforeTraverseEvent'
Can we move those events and their interfaces out into a non-zope.app package?
+1
E.g., the as-yet-notional zope.publication package you mention for phase 3?
Maybe. Or maybe zope.publisher.
Or zope.traversing?
-1. I want to make zope.traversing be less about publishing.
There are dependendencies on zope.app.publisher as well:
- Products.Five.browser.adding uses 'getMenu'.
- Products.Five.browser's configure.zcm uses IMenuItemType, MenuAccessView, and IMenuAccessView.
- Products.Five.form.metaconfigure uses menuItemDirective.
- Produts.Five.viewlet.metaconfigure uses viewmeta.
- Products.Five.fivedirectives uses IBasicResourceInformation.
The first two may be the only real uses of the menu framework you discuss above.
I wouldn't be surprised if others used it too. (ZC might :) Jim -- Jim Fulton Zope Corporation
On Sunday 21 June 2009, Jim Fulton wrote:
Thoughts?
+1. Sounds really good! BTW, I would love to hear about a practical example for overriding proxy() other than turning off security altogether. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
On Jun 21, 2009, at 9:40 PM, Stephan Richter wrote:
On Sunday 21 June 2009, Jim Fulton wrote:
Thoughts?
+1. Sounds really good!
BTW, I would love to hear about a practical example for overriding proxy() other than turning off security altogether.
2 examples: - Use a Python-based proxy that's good enough for supporting access control in trusted code. (It wouldn't protect against devious untrusted code, but most applications don't really need to run untrusted code.) - Use a better system for managing checkers. Probably the most important feature is disabling proxy-based protection for applications that don't need an access control model or that use a non-proxy-based approach. Jim -- Jim Fulton Zope Corporation
HI Big +1 from me on this. I had to do a whole lot of hacks to get this stuff running on app engine and basically had to gut zope.proxy which was ugly and obviously unsupported. After getting this running which was a big task I decided to go with repoze.bfg which just didn't have the security proxies at all because I wouldn't have to support my wierd gutted fork of zope.proxy and zope.security. (under gae I am not running any untrusted code) Having a standard way to turn this stuff would be great, Rgds Tim On Mon, Jun 22, 2009 at 5:36 PM, Jim Fulton <jim@zope.com> wrote:
On Jun 21, 2009, at 9:40 PM, Stephan Richter wrote:
On Sunday 21 June 2009, Jim Fulton wrote:
Thoughts?
+1. Sounds really good!
BTW, I would love to hear about a practical example for overriding proxy() other than turning off security altogether.
2 examples:
- Use a Python-based proxy that's good enough for supporting access control in trusted code. (It wouldn't protect against devious untrusted code, but most applications don't really need to run untrusted code.)
- Use a better system for managing checkers.
Probably the most important feature is disabling proxy-based protection for applications that don't need an access control model or that use a non-proxy-based approach.
Jim
-- Jim Fulton Zope Corporation
_______________________________________________ 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 )
On Jun 22, 2009, at 7:11 AM, Tim Hoffman wrote:
Big +1 from me on this.
Cool.
I had to do a whole lot of hacks to get this stuff running on app engine and basically had to gut zope.proxy which was ugly
How so?
and obviously unsupported.
I don't think so. What makes you think it's unsupported. Jim -- Jim Fulton Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
On Jun 22, 2009, at 7:11 AM, Tim Hoffman wrote:
Big +1 from me on this.
Cool.
I had to do a whole lot of hacks to get this stuff running on app engine and basically had to gut zope.proxy which was ugly
How so?
and obviously unsupported.
I don't think so. What makes you think it's unsupported.
I think Tim was referring to his mangled version of zope.proxy (no C extensions, to allow running on GAE). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKP4WJ+gerLs4ltQ4RAi4IAJwM3/1FoX027kHSQKTzNCW0qYewJACdFQ+4 tRgPtbJCmsMed1HNugqk9os= =znBD -----END PGP SIGNATURE-----
On Jun 22, 2009, at 9:22 AM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
On Jun 22, 2009, at 7:11 AM, Tim Hoffman wrote:
Big +1 from me on this.
Cool.
I had to do a whole lot of hacks to get this stuff running on app engine and basically had to gut zope.proxy which was ugly
How so?
and obviously unsupported.
I don't think so. What makes you think it's unsupported.
I think Tim was referring to his mangled version of zope.proxy (no C extensions, to allow running on GAE).
Ah. Never mind. (/me says with a little old lady's voice) :) Jim -- Jim Fulton Zope Corporation
Hi Jim Yeah I meant my ugly hacks getting rid of the 'c' in zope.proxy and zope.security aren't going to get supported by anyone, whereas having a supported way of substituting proxies and security would be great. All the import dependancies that existed when I went through the excercise meant ugly hacks was about all I could come up with. The refactoring going on at the moment is fantastic. T On Mon, Jun 22, 2009 at 9:22 PM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
On Jun 22, 2009, at 7:11 AM, Tim Hoffman wrote:
Big +1 from me on this.
Cool.
I had to do a whole lot of hacks to get this stuff running on app engine and basically had to gut zope.proxy which was ugly
How so?
and obviously unsupported.
I don't think so. What makes you think it's unsupported.
I think Tim was referring to his mangled version of zope.proxy (no C extensions, to allow running on GAE).
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFKP4WJ+gerLs4ltQ4RAi4IAJwM3/1FoX027kHSQKTzNCW0qYewJACdFQ+4 tRgPtbJCmsMed1HNugqk9os= =znBD -----END PGP SIGNATURE-----
_______________________________________________ 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 )
On Monday 22 June 2009, Jim Fulton wrote:
2 examples:
- Use a Python-based proxy that's good enough for supporting access control in trusted code. (It wouldn't protect against devious untrusted code, but most applications don't really need to run untrusted code.)
- Use a better system for managing checkers.
Probably the most important feature is disabling proxy-based protection for applications that don't need an access control model or that use a non-proxy-based approach.
Thanks, that helps me to put a context around the discussion. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
On Sun, Jun 21, 2009 at 11:55:50AM -0400, Jim Fulton wrote:
- It aggressively proxies objects using zope.security.checker.ProxyFactory. Some people don't want to use proxies and those that do might want to use a different proxy or checker implementation.
Grok's publication sub-class is similar to mine: http://svn.zope.org/grok/trunk/src/grok/publication.py?view=markup We I think we both want security proxies around views, but not during traversal. I've also heard of people who want proxies around the context and view, but not during traversal. It's pretty difficult to do the above securely, or at least I was able to open massive security holes while prototyping my publication object;) Witness grok's "if IBrowserView.providedBy" dance in the URL above.
Maybe in phase 3:
- Create zope.publication from zope.app.publcatiobn - use webtest rather than zope.app.testing.
What's webtest?
Thoughts?
Sounds good!
Jim
-- Jim Fulton Zope Corporation
_______________________________________________ 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 )
-- Brian Sutherland
On Jun 22, 2009, at 4:08 AM, Brian Sutherland wrote:
On Sun, Jun 21, 2009 at 11:55:50AM -0400, Jim Fulton wrote:
- It aggressively proxies objects using zope.security.checker.ProxyFactory. Some people don't want to use proxies and those that do might want to use a different proxy or checker implementation.
Grok's publication sub-class is similar to mine:
http://svn.zope.org/grok/trunk/src/grok/publication.py?view=markup
We I think we both want security proxies around views, but not during traversal. I've also heard of people who want proxies around the context and view, but not during traversal.
Yup. I've wanted something like that too.
It's pretty difficult to do the above securely, or at least I was able to open massive security holes while prototyping my publication object;) Witness grok's "if IBrowserView.providedBy" dance in the URL above.
It's actually pretty easy. All you have to do is make the traversal adapters public. There aren't very many of them.
Maybe in phase 3:
- Create zope.publication from zope.app.publcatiobn - use webtest rather than zope.app.testing.
What's webtest?
http://pythonpaste.org/webtest/ It's sort of like zope.app.testing.functional or zope.testbrowser but for WSGI apps. It *just* handles the publishing aspects of testing. Tests can then manage their own application setup. I think this will make many tests simpler and cleaner as they can set up just enough of an application as they need for their tests. Jim -- Jim Fulton Zope Corporation
On Mon, Jun 22, 2009 at 09:01:16AM -0400, Jim Fulton wrote:
- Create zope.publication from zope.app.publcatiobn - use webtest rather than zope.app.testing.
What's webtest?
http://pythonpaste.org/webtest/
It's sort of like zope.app.testing.functional or zope.testbrowser but for WSGI apps. It *just* handles the publishing aspects of testing. Tests can then manage their own application setup. I think this will make many tests simpler and cleaner as they can set up just enough of an application as they need for their tests.
Ah, very interesting, so far I've been using wsgi-intercept which is very similar and has been working well for me. http://code.google.com/p/wsgi-intercept/ Though webtest, re-using the WebOb request does look interesting. -- Brian Sutherland
Jim Fulton wrote: [snip[
I made it possible to override proxying by overriding the proxy method. At this point, I think zope.app.publication provides a pretty reasonable base class for custom publication implementations, although the module arrangement could be made a bit simpler.
Cool. :)
I propose the following:
In phase 1 reduce the scope of zope.traversing:
- Move path traversal code to zope.tales
I'm very much +1 for anything that moves ZPT-only traversal to places where it's less likely to confuse the reader of the code into thinking it's URL traversal.
- Move the URL traversal code used by zope.app.publisher.menu to zope.app.publisher.menu. Refactor it to use the request.publication. Deprecate definition of menu items without permissions.
I'm worried about how this affects dependencies. I wouldn't want, say, zope.container, zope.app.pagetemplate and zope.site to start depending on zope.app.publisher where now they depend only on zope.traversing (which is much more lightweight in the dependency department). If you can do this without making zope.container depend (indirectly) on zope.app.pagetemplate and the like, or, say, zope.site on zope.contenttype, then I'm +1. This means that we shouldn't make zope.traversing depend on zope.app.publisher at any stage, as this would completely screw up all graphs. The dependency for backwards compatibility should ideally be a loose one, not marked in the setup.py dependencies and only required if backwards compatibility is needed.
Thoughts?
Please do watch those dependencies... The z3c.recipe.depgraph buildout recipe can help you generate dependency graphs. Please watch the scc graphs to see whether you aren't inadvertently creating more cycles. Regards, Martijn
On Jun 22, 2009, at 2:51 PM, Martijn Faassen wrote:
Jim Fulton wrote: [snip[
I made it possible to override proxying by overriding the proxy method. At this point, I think zope.app.publication provides a pretty reasonable base class for custom publication implementations, although the module arrangement could be made a bit simpler.
Cool. :)
I propose the following:
In phase 1 reduce the scope of zope.traversing:
- Move path traversal code to zope.tales
I'm very much +1 for anything that moves ZPT-only traversal to places where it's less likely to confuse the reader of the code into thinking it's URL traversal.
- Move the URL traversal code used by zope.app.publisher.menu to zope.app.publisher.menu. Refactor it to use the request.publication. Deprecate definition of menu items without permissions.
I'm worried about how this affects dependencies. I wouldn't want, say, zope.container, zope.app.pagetemplate and zope.site to start depending on zope.app.publisher where now they depend only on zope.traversing (which is much more lightweight in the dependency department).
They wouldn't. They don't use the URL traversal code. Non-URL traversal code would move to zope.tales. zope.container would depend on zope.tales rather than on zope.traversing.
If you can do this without making zope.container depend (indirectly) on zope.app.pagetemplate and the like, or, say, zope.site on zope.contenttype, then I'm +1.
This means that we shouldn't make zope.traversing depend on zope.app.publisher at any stage, as this would completely screw up all graphs. The dependency for backwards compatibility should ideally be a loose one, not marked in the setup.py dependencies and only required if backwards compatibility is needed.
OK.
Thoughts?
Please do watch those dependencies... The z3c.recipe.depgraph buildout recipe can help you generate dependency graphs. Please watch the scc graphs to see whether you aren't inadvertently creating more cycles.
OK. Jim -- Jim Fulton Zope Corporation
Jim Fulton wrote:
They wouldn't. They don't use the URL traversal code. Non-URL traversal code would move to zope.tales. zope.container would depend on zope.tales rather than on zope.traversing.
For my own education, I would like to understand why it makes sense for zope.container to depend on zope.tales. This dependency suggests people need to understand ZPT in order to understand container relationships, which seems wrong to me. Shane
On Jun 23, 2009, at 2:36 PM, Shane Hathaway wrote:
Jim Fulton wrote:
They wouldn't. They don't use the URL traversal code. Non-URL traversal code would move to zope.tales. zope.container would depend on zope.tales rather than on zope.traversing.
For my own education, I would like to understand why it makes sense for zope.container to depend on zope.tales. This dependency suggests people need to understand ZPT in order to understand container relationships, which seems wrong to me.
Because it provides traversal adapters needed soley by zope.tales. Keep in mind that these adapters are currently for interfaces defined by zope.traversing, but these interfaces are only (or should only be) used by zope.tales. Of course, these adapters could be moved elsewhere. In fact, it would be best to move these adapters to zope.tales as well, as they will work for any mapping object, not just containers. There are also publishing adapters in zope.container that could probably move elsewhere, since they too will work with any mapping. I suspect when I really wade into this, I'll be able to propose some other cleanups. Jim -- Jim Fulton Zope Corporation
Jim Fulton wrote:
On Jun 23, 2009, at 2:36 PM, Shane Hathaway wrote:
Jim Fulton wrote:
They wouldn't. They don't use the URL traversal code. Non-URL traversal code would move to zope.tales. zope.container would depend on zope.tales rather than on zope.traversing.
For my own education, I would like to understand why it makes sense for zope.container to depend on zope.tales. This dependency suggests people need to understand ZPT in order to understand container relationships, which seems wrong to me.
Because it provides traversal adapters needed soley by zope.tales.
Sorry, you lost me on the first sentence (and the rest doesn't make sense yet to me as a result). You first said that zope.container is going to depend on zope.tales. Now you're saying zope.tales is going to depend on zope.container. If you meant the latter, then I understand. :-) Shane
On Jun 23, 2009, at 3:02 PM, Shane Hathaway wrote:
Jim Fulton wrote:
On Jun 23, 2009, at 2:36 PM, Shane Hathaway wrote:
Jim Fulton wrote:
They wouldn't. They don't use the URL traversal code. Non-URL traversal code would move to zope.tales. zope.container would depend on zope.tales rather than on zope.traversing.
For my own education, I would like to understand why it makes sense for zope.container to depend on zope.tales. This dependency suggests people need to understand ZPT in order to understand container relationships, which seems wrong to me. Because it provides traversal adapters needed soley by zope.tales.
Sorry, you lost me on the first sentence (and the rest doesn't make sense yet to me as a result). You first said that zope.container is going to depend on zope.tales. Now you're saying zope.tales is going to depend on zope.container. If you meant the latter, then I understand. :-)
Where did I say that zope.tales is going to depend on zope.container? It would have been more precise if I has said that "it provides traversal adapters used soley by zope.tales". zope.containers provides adapters to do path traversal. ZPT is the only thing that does path traversal. Jim -- Jim Fulton Zope Corporation
participants (7)
-
Brian Sutherland -
Jim Fulton -
Martijn Faassen -
Shane Hathaway -
Stephan Richter -
Tim Hoffman -
Tres Seaver