World: r3wp

What happens after that is up to the OS's loader.

Your first sentence above is, for example, simply wrong on almost 
any Unix.

well how do you install zlib.so on a system that already has this 
?

knowing that the zlib.so actually is only a stub for the real one.

Properly manage the loader's search path.

And don't make stupid naming decisions.

You probably don't want to name your extension kernel32.dll or libc.so.

problem is, I have no clue what names are being used in all the OSes 
out there.  so we end up with having to use crude and ugly prefixes, 
hoping no one else will ever setup the same lib name.

Same difference to hoping that no one will ever use the same library 
suffix.

Those are problems mitigable by many approaches, such as library 
search path management or proper distribution.

yes, I know... what I want is for R3 to control the lib search path 
not the user ... I'm sure all OSes allow this.  R3 would only load 
extensions in a single place it expects.

That doesn't make sense across platforms.

You probably want and need that on Windows.

You probably don't want and need that on other platforms.

Btw, there are two places where a "user" could control the search 
path. From within R3 or from the outside.

no difference on windows.  they all do the same basic path searching. 
 local and then system paths.

windows actually has a registry of name/version numbers when dlls 
are installed properly, which helps a lot.

Btw, we already have system/options/module-paths in R3.

I want to be able to setup a R3 config file that says:

extensions-dir:  %/some/path/


and then R3 will only ever load extensions from there.    the extensions 
can do whatever they want, but we have a controled point of entry 
within REBOL.

afaik, systems allow paths on dlopen.    rebol would simply always 
ask for libs with paths... 


in fact, on windows, that is how you are supposed to do it, probing 
the registry first to get proper paths for libs.

The "will only ever" is wrong, here.

yeah, I know.   but modules and extensions are very different things.

(my last post refered to system/options/module-paths)

An extension search path should be consulted first, that's what you 
really want to say :)

Even though the practicaly difference will be negligible.

no... only.  I really don't want rebol to start playing around in 
the OS, looking for extensions, if I set up a unique path.  really.

And point well taken: you don't want the "system paths" searched, 
esp in the context of Win32.

REBOL could very well setup things like local paths if the extension-dir 
is setup as a block with fallbacks...  which make the loading of 
application libs portable.

by portable, I mean install path independent.

My whole point is: you want those paths _preferred_, but ultimately, 
if you don't find an extension in those paths, you should just fall 
back to the OS loader's search path mechanism.

This allows distributions with a strong library management to properly 
and fully integrate R3 into the OS.

And for everyone else it makes no real difference.

a lot of things in R2 are frustrating, one of them is the ability 
to "clamp down" an environment in which you *know absolutely* where 
files are being searched and stored relative to the running app. 
 distributing apps in a multi-user setup where apps are installed 
on network disks, is impossible to properly clamp down unless you 
use absolute paths in the application itself.


I also want to be able to tell it not to fallback.  though, by default, 
defaulting is usefull, I agree.


for example, I want to be able to make sure that whatever happens, 
a local machines libs will never be accessed, cause that can lead 
to people overiding an install which has serious security considerations.

though the install path may change from one user to the next, so 
absolute paths in the application might not make sense.


I just providing these examples, cause they have actually hapened 
to me in a 100+ employe setup where we had applications being setup 
on the fly on login.

with rebol, one could always break the install easily, since you 
can't easily force it into a corner.

Platform-specific distribution problems, once again.

If you don't want your loader to look into the system paths for a 
specific app, tell it not to do so.

But leaving that aside, this specific item is a very simple flag 
that can be exposed from within R3 as well.

Though I doubt it will be necessary.

myself I have about 10 different rebol installs, they are all setup 
differently.   some I'd like to lock down, but I can't unless I build 
a special version of R3.


If we want REBOL to allow strong security on all platforms, it has 
to be *able* to manage the search paths on its own.   cause all platforms 
will have different working models.


another example is for a web plugin that allows extensions.  we don't 
want it to look for its extensions anywhere else than in a path that 
its managing.


I don't want to have to invent this system everytime I build a new 
system built with R3

I'd say that the chances that a R3 extension you forgot to bundle 
with your app happens to linger around in the Win32 system paths 
are pretty slim :)

hehe.

If we want REBOL to allow strong security on all platforms

 -- once we get to dynamically loadable native extensions, this definitely 
 becomes an illusion.

my concern is about willfull hacking and the ability for the intepreter 
to allow strong security out of the box... if you need it.

not when you are the one building the extensions and you know exactly 
what extensions can be loaded.

building can also include installing.

If you want R3's supposed strong security, you can't load native 
extensions. Simple as that :)

Whatever, I think we are in violent agreement here.

hehe

Roughly summarising: an extension search path (preferred) + os loader 
search (fallback) + a cross-platform mechanism to load extensions 
via abstract names.


Could be as simple as reusing system/options/module-paths and load-extension, 
allowing the latter to take a word! parameter and also search the 
former. The possible extensions themselves are already in place (system/options/file-types). 
Loading is already done via dlopen, so loading a lib only by name 
(w/o any path component) will use the OS loader's search mechanisms.


And alternative would be to add a system/options/extension-paths 
(block!) option, and a dedicated loading primitive, say, import-extension, 
which searches the extension-paths and tries all possible platform-specific 
extensions (as per system/options/file-types).

good summary.  I'd like brian To add his grain of salt, as he might 
have other insight, but I think this allows us full control along 
with full flexibility.