World: r3wp

I think that is the real reason the default is set to .reb: Noone 
uses it. People either use .r or .r3, and you are expected to change 
system/options/default-suffix to what you need it to be. That is 
the reason it's a system option.

we are very flexible, what do users think? I want free buttons, different 
extensions. I hope R4 prohibits user to load script, that would be 
best - we should be strict :-)))

No separate extension for compressed scripts is needed, as all scripts 
can be compressed. For that matter, script-encoded compressed scripts 
can even be colorized, though the data is just a big binary. Again, 
YMMV, you might have another opinion about this :)

pekr... "we should be strict "   hahaha    ;-)

if people are distributing their files in a single dir, they will 
have .so, .dll  in the same dir.


can't we just build a little .r file which imports the proper lib, 
no?

Many of you are conflating distribution and usage here.

Distribution is an entirely different matter to what Kaj is getting 
at.

Once your libraries are distributed (and installed), you already 
have the proper library suiting your specific platform.

You won't have 4 .dll's and 10 .so's. You will have _one_ file that 
suits your platform.

And as R3 extensions are loaded via the platform's regular loader, 
you can utilise all the features of said loader.

At which point it makes a _lot_ of sense to not artificially hide 
an R3 extension's nature as dynamic library and just use the platform-specific 
conventions.

Which will generally lead to better tool support and acceptance.

Now for most extensions they: a) won't be delayed extensions built 
into the host, and b) will easily be cross-platform across at least 
some platforms.

Having a simple cross-platform way to load those extensions while 
not imposing artificial naming constraints would be _extremely_ useful.

This is what Kaj is proposing, and I couldn't agree more.

The desired mechanism is simple: give an abstract name, have the 
platform-specific extension taken care of automatically, and then 
fall back to the loader.

And this really ought to be part of the "standard" R3 distribution, 
as it will be used widely and we want to be able to rely upon it 
being there.

I've used a few applications which have their own extension names 
simply because there is a lot of overlap in names and clashing with 
the OS is very easy at some point.

I use many applications which don't use their own extension names.

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.