At this point I can say I don't honestly care all that much, and most of my worries are based on vague feelings that there are platforms out there where finding the actual executable name is somewhere between hard and impossible. I will, then, do the sensible thing and just punt on this--we can work out a best practices thing and enshrine it as the default on systems which can support it and be done with it.
The other question, then, is do we see the need for multiple categories of library which would want separately settable library paths?
Wouldn't it be sensible to build something robust enough to also solve the problems of finding parrot user libraries and user resources? In which case, a static search path is decidedly retro. It would hardly make sense to not include, at the front of the search path, directories relative to the PBC file trying to find its libraries or resources.*
For finding resources, one doesn't generally want to fall back to system paths. Finding libraries is another matter.
Then there's the mention of using URLs to load resources (e.g., over HTTP). Which seems sensible and forward-thinking to me.
Which suggests to me a linked list of resource resolvers. First one in the chain to return a file handle to the data or PBC wins. The head of parrot's own "system" chain would be available to be appended to any other chains that wanted it.
—
Gordon Henriksen [EMAIL PROTECTED]
(* - The directory containing every loaded PBC file is not at all important; consider an application like Apache+mod_parrot which is loading multiple independent PBC files. It would be useful to allow the administrator to install both the production PBC in addition to a development release of the same application on the same web server [just at different paths], with confidence that mod_parrot won't get the two confused. [IIS can do this. It's very cool.])
