World: r3wp

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.

(and minimal fuss when it doesn't matter)

Many of you are conflating distribution and usage here.

Exactly

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

Yes, these are also being conflated in these arguments

how so?

As you said, they're different. For example, system/options/module-paths 
is needed for REBOL modules, but it doesn't work for extensions

You want an optional search path for extensions, and that's fine, 
but Andreas and I are pleased with the OS managing them

ok yes.

I'd also be fine with having module-paths used for extensions as 
well (before falling back on the OS search paths). In fact, I would 
prefer re-using module-paths over adding another extension-paths 
option.

While there wouldn't be a point to the OS managing REBOL modules, 
because it doesn't know what they are

But in any case, as you say, _don't_ take away the ability to just 
have extension search managed by OS mechanisms.

Exactly, and in a portable way

If you want to fully integrate R3 into an OS, that is a job for the 
host code. For most OSes you want as much isolation between the OS 
and R3 as you can get. Unless you have a locked-down OS (most don't) 
then what constitutes a "safe" extension would vary widely between 
programs. That is why the module-paths option and others like it 
are just set by default by the startup code, to be changeable by 
the program code as needed.

We do have a way to have extension search managed in a portable way 
by OS-specific means: LOAD-EXTENSION is implemented in the host code.

Yes, and all we need to do is add some simple filename management 
to it.

Which doesn't make any sense at all to replicate for each and every 
otherwise portable extension.

Sigh. I'm not going to spend another day rehashing that it's currently 
not portable, because of the very simple detail Andreas says

Yup. But keep in mind that for most potential R3 users (who like 
most users are running Windows, OSX or some stock Linux) the OS mechanisms 
for managing libraries shared between programs are really poor, and 
they are encouraging program-specific storage. I'm really interested 
in how you will experiment with integrating R3 with a properly managed 
OS, which (I hope) Syllable is.

loader mechanisms on linux are anything but poor (at least compared 
to windows)

Damned by faint praise, but true. The real trick is to make sure 
that LOAD-EXTENSION doesn't try to load non-extension system libraries.

why? it will fail anyway

no need to needlessly overcomplicate things

Even though Syllable has its own dynamic loader in the kernel, we're 
not managing user space libraries vastly differently than Linux, 
which has a user space loader. The difference is in kernel drivers, 
which are standard ELF libraries just like user space libraries, 
which isn't possible in Linux. I consider this similar to the nice 
circumstance that R3 extensions are native OS libraries, which has 
similar integration benefits - if you take advantage of them