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
