World: r3wp

I'd prefer using system names, only not the system load path management. 
  Rebol, should only look for R3 extensions withing its path configs... 
whatever they are... the R3 extensions *will* use the OS loading 
path, which is normal, since the extension is in fact a bridge between 
the OS and rebol.

And name clashes is what a proper loader is there to take care of.

The OS's shared library loader, that is.

so if a rebol zlib interface is installed, I want the r3 module to 
be loadable using   IMPORT zlib     ... not r3zlib.

Doesn't necessarily have to be IMPORT. I agree with Brian that we 
probably want to have extension loads "stand out" a bit.

it goes beyond name clashes... R3 extensions have a specific duty, 
we are not loading OS libs directly within R3... import must not 
try to access these.


I would prefer to have a specific loader for extensions something 
like.

EXTEND my-extension

which could allow .rx and platform .so or .dll to match the name.

But I want to do `import-extension 'zlib` and not:

import switch system/platform/1 [Linux [%zlib.so] Win32 [%zlib.dll] 
...]

yep we agree.   but I like having .rx also.    its something pretty 
standard on windows to have different names for dlls... the OS itself 
uses different names for various subsystems.

I couldn't care less about .rx.

It's fine if you want to use it, but it makes no difference at all.

Use .rx on Win32, Linux, FreeBSD and whereever you feel like it; 
just don't prescribe its use.

I'd just leave that up to the developper's  as long as the extension 
loader supports both   :-)

It's not only the developers choice, there are also distributors.

But it's easy enough to have the extension loading mechanism support 
multiple extensions per platform.

That's just a matter of definition.

(I.e. define the order in which multiple extensions are attempted 
and define which extensions are attempted on each platform.)

my only issue is that the interpreter musn't look for extensions 
in OS paths cause that will invariably lead to library management 
issues.   


many extensions are simply stubs for real OS libs.  furthermore, 
some stray lib could be picked up and cause dangerous side-effects 
when run by the interpreter.


if an R3 os package is built, any extension packages which are built 
for it, should dump the files in R3's own unique search-path setup.

Maxim, R3 does a simple `dlopen`.

It does no "looking" at all.

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.