You are viewing a plain text version of this content. The canonical link for it is here.
Posted to axkit-dev@xml.apache.org by Jörg Walter <jw...@garni.ch> on 2003/09/17 23:56:51 UTC
Pseudo-Protocols
Hi!
I have just commited a pseudo-protocol registry which should ease the
implementation of new pseudo-protocols similar to "axkit:". It replaces these
specific hacks with one generic solution. Behaviour should not change in any
circumstance.
Two providers that use this feature are the XMLDB provider now available from
my CVS repository (there was already a hack for it inside axkit which is now
gone, too), and my SQL provider from the same site which is still ongoing
work...
Please review the change and tell me if you see any problems.
--
CU
Joerg
PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
Re: Pseudo-Protocols
Posted by Jörg Walter <jw...@garni.ch>.
On Friday, 19. September 2003 16:31, Kip Hampton wrote:
> > I can easily back out the change in XPathScript, as it is the only module
> > not working. The others work well even on several of my large sites using
> > all sorts of file://, sql://, document_root relative and axkit:// URIs
> > from within XSLT, XSP and XInclude. Thus I would like to leave the rest
> > in place, as it is obviously working and at least one of our long-time
> > users asked me when this feature is going in.
>
> "Works fine here" is nice, but it is not the criteria for checking
> significant changes into the main branch. I'm sorry if you've been misled.
It is not a significant change. It doesn't change anything at all, from the
application's point of view. Which is a lot less intrusive than many other
changes we did.
And I have checked that with three rather complex sites I maintain - sites
which tend to break (and repeatedly did break) due to many other changes, be
they because of libxslt, XML::LibXSLT, libxml, and several changes in AxKit
semantics since 1.5.$something. These sites, which use lots of different URL
inclusion mechanisms (all of them, except XPathScript based), worked
flawlessly with the patched version. I consider this a good and sufficient
real-world test.
I apologoze for the problems with XPathScript - it would have been better to
ask someone actually using that and/or better aquainted with it to do the
modifications.
> First, make sure that you have the latest Apache::Test from CPAN. Past
> that, I'm not exactly sure which docs you're looking at, but the one
> here [1] shows that you can pass the -httpd option with an appropriate
> path to the t/TEST script to indicate the Apache binary you which to
> test against. That is (in the root of the AxKit dist):
>
> perl t/TEST -httpd /path/to/your/apache
These were the docs, my friend, the docs that never end... umm, I mean, that
didn't include any help as to why it either picked up the wrong httpd (on a
box where it didn't matter anyways, as 'the correct one' would have been
apache2), created a broken config file the httpd couldn't grok, or the one
most promising case when everything looked fine but the httpd silently didn't
start.
> A quick look at "perl t/TEST -help" yields many more options that might
> help you along.
Thanks for the tip, I will give it another try... though I really wonder why
it is hidden? Even Apache::Test itself doesn't install, it doesn't ask for
any paths at installation time, and the readme file is likewise unhelpful.
All this even though all machines now use stock distro httpds (btw, a nice
fact... these days this really works).
> Assuming that this gives you a working test environment, I'm confident
> that you'll not only fix the current XPS bug, but also include a series
> of tests that exercise your changes for each module they effect; or,
> barring those, that you will back you changes out as requested.
The changes don't effect anything as long as you don't use the new API. That's
by intention. But I will gladly add some problematic cases from the mentioned
past experiences into the test, should I get Apache::Test running this time.
I've given up on that several times before.
The current XPS bug is already fixed by reverting the untested changes.
> > Finally, is this list archived somewhere? I have been thrown off due to
> > my mail disaster a few weeks ago and would like to catch up with mails.
>
> http://nagoya.apache.org/eyebrowse/SummarizeList?listId=50
Thanks.
--
CU
Joerg
PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
Re: Pseudo-Protocols
Posted by Kip Hampton <kh...@totalcinema.com>.
Jörg Walter wrote:
> On Friday, 19. September 2003 09:57, Matt Sergeant wrote:
>>Since it broke the test suite, can you back out the change and check it
>>in on a branch. Thanks.
>
>
> I can easily back out the change in XPathScript, as it is the only module not
> working. The others work well even on several of my large sites using all
> sorts of file://, sql://, document_root relative and axkit:// URIs from
> within XSLT, XSP and XInclude. Thus I would like to leave the rest in place,
> as it is obviously working and at least one of our long-time users asked me
> when this feature is going in.
"Works fine here" is nice, but it is not the criteria for checking
significant changes into the main branch. I'm sorry if you've been misled.
>
> I'd also love to test it, but Apache::Test is not working on any machine I
> have access to, and never has in the past. Does anyone have any hints how to
> get a working Apache::Test setup? The docs show no hint of troubleshooting
> options, and it is constantly picking up the wrong httpd (/usr/sbin/httpd
> isn't always apache), or writing a config the apache doesn't grok.
First, make sure that you have the latest Apache::Test from CPAN. Past
that, I'm not exactly sure which docs you're looking at, but the one
here [1] shows that you can pass the -httpd option with an appropriate
path to the t/TEST script to indicate the Apache binary you which to
test against. That is (in the root of the AxKit dist):
perl t/TEST -httpd /path/to/your/apache
A quick look at "perl t/TEST -help" yields many more options that might
help you along.
Assuming that this gives you a working test environment, I'm confident
that you'll not only fix the current XPS bug, but also include a series
of tests that exercise your changes for each module they effect; or,
barring those, that you will back you changes out as requested.
>
> Finally, is this list archived somewhere? I have been thrown off due to my
> mail disaster a few weeks ago and would like to catch up with mails.
http://nagoya.apache.org/eyebrowse/SummarizeList?listId=50
-kip
[1] http://perl.apache.org/docs/general/testing/testing.html
Re: Pseudo-Protocols
Posted by Matt Sergeant <ma...@sergeant.org>.
On 19 Sep 2003, at 10:52, Jörg Walter wrote:
> Finally, is this list archived somewhere? I have been thrown off due
> to my
> mail disaster a few weeks ago and would like to catch up with mails.
http://nagoya.apache.org/eyebrowse/SummarizeList?listId=50
I'll update the mailinglists.xml file to reflect that.
Re: Pseudo-Protocols
Posted by Jörg Walter <jw...@garni.ch>.
On Wednesday, 24. September 2003 20:18, Kip Hampton wrote:
> On the one hand, I think users would greatly benefit from having things
> like document('xmldb://whatever/query') "just work" from within XSLT and
> XPathScript stylesheets, but I can't help thinking that we'd be opening
> a real can of worms for ourselves in terms of managing the various
> callback interfaces between Language modules and whatever scheme
> handlers we might create. I don't find custom Providers hard to write,
> and if I don't want URLs for "internal" data URLs to be visible to the
> public, then, well, I simply don't mention/link to them in the contents
> of the site... *shrug*
Well, we are not really creating a second interface or API - this is the main
point of the registry, it simply allows a provider to register itself as the
foobar:// handler, and then the regular provider code is used. No code
duplication at all. The first step is still to write the provider.
(Okay, there is an additional feature by which any sub could be used as
callback, but that's more or less just for backwards compatibility with the
old, undocumented $provider_cb feature. If we removed that, I would be glad,
but I don't know who uses $provider_cb and why it was introduced)
Security by obscurity, on the other hand, has always been a genuinely bad
idea, and in some cases it would be stupid to configure a database in a
public location - imagine customer data with credit card numbers or so.
Access control is so easy to get wrong, and "non-announced" locations are
often easy to guess. Using pseudo-schemes is a more error-resilient design,
and easier to configure as well.
--
CU
Joerg
PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
Re: Pseudo-Protocols
Posted by Kip Hampton <kh...@totalcinema.com>.
After careful thought, I'm still of two minds about the advisability of
doing URI-scheme bindings inside AxKit.
On the one hand, I think users would greatly benefit from having things
like document('xmldb://whatever/query') "just work" from within XSLT and
XPathScript stylesheets, but I can't help thinking that we'd be opening
a real can of worms for ourselves in terms of managing the various
callback interfaces between Language modules and whatever scheme
handlers we might create. I don't find custom Providers hard to write,
and if I don't want URLs for "internal" data URLs to be visible to the
public, then, well, I simply don't mention/link to them in the contents
of the site... *shrug*
-kip
Re: Pseudo-Protocols
Posted by Jörg Walter <jw...@garni.ch>.
On Friday, 19. September 2003 21:38, Matt Sergeant wrote:
> On 19 Sep 2003, at 10:52, Jörg Walter wrote:
> > I can easily back out the change in XPathScript, as it is the only
> > module not
> > working. The others work well even on several of my large sites using
> > all
> > sorts of file://, sql://, document_root relative and axkit:// URIs from
> > within XSLT, XSP and XInclude. Thus I would like to leave the rest in
> > place,
> > as it is obviously working and at least one of our long-time users
> > asked me
> > when this feature is going in.
>
> I think the bigger issue is we haven't really discussed this feature.
> Are we sure alternate URI schemes is the best way to do this? What
> makes this better than a provider for anything other than axkit://?
Basically, there are two use cases. The one is if you want to include data
which you don't want to be available via the web. You'd have to configure an
apache subdir with the providers, then put access control into place but see
that it doesn't mess with your own retrievals, and finally get stuck as axkit
uses either the current style provider or the content provider, not the one
configured in the target location. Big trouble to set up and get working.
Contrast this to an XMLDB repository, where you would simply retrieve
"xmldb://collection/subcollection/document.xml". No setup, just load the
module and you are up and running. No accidental external accesses, no
provider messup. This is just like "file://" - it isn't strictly neccessary,
since you could simply configure apache for the requested location, and yet
repeatedly people use that since the other way is much too complicated.
Don't confuse this with URLs that contain queries or something - this is a
simple, plain document retrieval mechanism, it is not designed to extend URL
retrievals into a query mechanism.
The second use case is for the case you use the FileWrite provider (or my
XMLDB or SQL providers, that are API-compatible). In an XSP page, you usually
have to go through several steps to get a provider - if the target doesn't
exist yet, it sometimes is even more difficult. Now a simple get_uri()-call
is sufficient. Of course, the write-back support being experimental in
itself, this isn't as important, but still, there is an advantage.
--
CU
Joerg
PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
Re: Pseudo-Protocols
Posted by Matt Sergeant <ma...@sergeant.org>.
On 19 Sep 2003, at 10:52, Jörg Walter wrote:
> I can easily back out the change in XPathScript, as it is the only
> module not
> working. The others work well even on several of my large sites using
> all
> sorts of file://, sql://, document_root relative and axkit:// URIs from
> within XSLT, XSP and XInclude. Thus I would like to leave the rest in
> place,
> as it is obviously working and at least one of our long-time users
> asked me
> when this feature is going in.
I think the bigger issue is we haven't really discussed this feature.
Are we sure alternate URI schemes is the best way to do this? What
makes this better than a provider for anything other than axkit://?
I get the feeling Kip has something to say about it, but he wants a
call to discuss it first. Here's that call.
Matt.
Re: Pseudo-Protocols
Posted by Jörg Walter <jw...@garni.ch>.
On Friday, 19. September 2003 09:57, Matt Sergeant wrote:
> On 17 Sep 2003, at 22:56, Jörg Walter wrote:
> > I have just commited a pseudo-protocol registry which should ease the
> > implementation of new pseudo-protocols similar to "axkit:". It
> > replaces these
> > specific hacks with one generic solution. Behaviour should not change
> > in any
> > circumstance.
> >
> > Two providers that use this feature are the XMLDB provider now
> > available from
> > my CVS repository (there was already a hack for it inside axkit which
> > is now
> > gone, too), and my SQL provider from the same site which is still
> > ongoing
> > work...
> >
> > Please review the change and tell me if you see any problems.
>
> Since it broke the test suite, can you back out the change and check it
> in on a branch. Thanks.
I can easily back out the change in XPathScript, as it is the only module not
working. The others work well even on several of my large sites using all
sorts of file://, sql://, document_root relative and axkit:// URIs from
within XSLT, XSP and XInclude. Thus I would like to leave the rest in place,
as it is obviously working and at least one of our long-time users asked me
when this feature is going in.
I'd also love to test it, but Apache::Test is not working on any machine I
have access to, and never has in the past. Does anyone have any hints how to
get a working Apache::Test setup? The docs show no hint of troubleshooting
options, and it is constantly picking up the wrong httpd (/usr/sbin/httpd
isn't always apache), or writing a config the apache doesn't grok.
Finally, is this list archived somewhere? I have been thrown off due to my
mail disaster a few weeks ago and would like to catch up with mails.
--
CU
Joerg
PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
Re: Pseudo-Protocols
Posted by Matt Sergeant <ma...@sergeant.org>.
On 17 Sep 2003, at 22:56, Jörg Walter wrote:
> I have just commited a pseudo-protocol registry which should ease the
> implementation of new pseudo-protocols similar to "axkit:". It
> replaces these
> specific hacks with one generic solution. Behaviour should not change
> in any
> circumstance.
>
> Two providers that use this feature are the XMLDB provider now
> available from
> my CVS repository (there was already a hack for it inside axkit which
> is now
> gone, too), and my SQL provider from the same site which is still
> ongoing
> work...
>
> Please review the change and tell me if you see any problems.
Since it broke the test suite, can you back out the change and check it
in on a branch. Thanks.