Gisle Aas wrote:
Tim Brody <[EMAIL PROTECTED]> writes:
But anyway, paging URI maintainer(s), respond please! (Can I invade URI::openurl, or can we shift this module into the URI distro.?)
I tried to skim the spec and your manpage and I still don't really understand what this is supposed to do. I does not look like openurl: is really supposed to be a URI scheme. The names URL::xxx where xxx is all lowercase is reserved for proper schemes.
You are correct.
I suggest you make your thing occupy the URI::OpenURL namespace and that you should not try to subclass URI. Just make your thing reference and delegate to URI objects where it makes sense. I don't think OpenURL fit in the URI distribution, so it is best distributed separately.
I quite like the subclassing though, as it will provide the accessors that URI has to an OpenURL (scheme/host/port/query).
The term ContextObject seems central. Looks like you should have a class called URI::OpenURL::Context that you instantiate in the API.
The ContextObject (by my understanding) is all of the OpenURL query component, so I don't think there would be much value in abstracting further (ContextObject + Resolver URL = OpenURL?), as long as the performance hit of storing the structured data as part of the URL isn't too bad ...
I'll ask for URI::OpenURL in CPAN, as it can always be changed to use a more structured back-end (which could tie into an eventual XML::ContextObject).
Thanks, Tim.
