World: r3wp

I said system/options/default-suffix because it's settable, even 
at runtime, not to suggest that you can use .reb for your extensions.

That seems to me to be a much bigger security hole

It's program-local. The program should protect that setting if it 
is going to load untrusted code.

The translation of .rx to .so and .dll sounds like the proper solution

Not .dll - it would only be required on platforms with a restriction 
on filenames that can be loaded as libraries. On windows there are 
dozens of different suffixes that are all basically DLLs, including 
.exe, .ocx, .dpl, .cpl, etc. Not many platforms restrict the file 
suffixes of libraries.

I'm not so much concerned about the ability of the base operating 
systems, but all the tools out there that expect conventions

If the problem wouldn't exist, then why define both .rx and .so in 
the first place?

But in general extensions are considered to be unsafe and platform-specific 
unless they are embedded in the host. For that matter, they aren't 
even loadable by default, as a security setting. Cross-platform external 
extensions are expected to be rare, but just in case we have the 
.rx suffix if you want to use them in cross-platform code.

I don't have to disable any security to load extensions on POSIX

>> secure 'query
SECURE is disabled

Security doesn't work in a110.

Sorry, that's just weird. I expect most extensions to be cross-platform

That is why we have .rx, for cross-platform extensions. They are 
supposed to stand out, so you know they're R3 extensions instead 
of normal libraries. For that matter, they are also supposed to support 
writing .rx loaders for built-in .dll or .so libraries that you didn't 
even write, even with the same name (except the suffix) in the same 
directory if you like.

It's the same reason Windows has .dll, .exe, .ocx, .cpl, etc. All 
DLLs, but different expectations for what functions are exported 
and how they're called.

Of the few tools I use, I already know one that I will have to modify 
for this non-standard extension

Which tool? I'm curious. Which platform has this restriction?

Builder on Syllable

It's my own tool, so it's not a big deal, but people will run into 
tools that they can't easily modify

Can Syllable load dynamic libraries with arbitrary file suffixes?

Yes, but as I said, that's not my main concern. It's the breaking 
of the convention that will trip up as-yet unknown tools

And there may be other operating systems that are less flexible

Those operating systems shouldn't add %.rx to file-types then - the 
code that sets that is in the host. Some platforms are less cross-platform 
than others.

That leaves the main problem that the user-level REBOL code is not 
cross-platform

Do you have a problem with making an embedded delayed extension that 
loads cURL dynamically when the extension is imported? This is supposed 
to be possible, and is the main reason for delayed modules and extensions. 
Then only programs with Needs: [curl] would initialize curl.

It's really quite simple: there are two worlds here, and if REBOL 
pretends to be cross-platform, it needs to bridge them

R3 external extensions don't pretend to be cross-platform; if they 
are, it's a bonus. Only embedded extensions pretend to be cross-platform.

That's a disaster, then. But it's really very simple to avoid it

This group here is where cross-platform starts going away.

Nonsense. R3 is cross-platform, cURL is cross-platform, and the extension 
compiled on Linux even runs on Syllable

I haven't touched Windows in years, and I never wanted to be a Windows 
C programmer, but now I am, just because Oldes and Andreas compiled 
my extension on it

what is the trouble here? Calling R3 extensions 'rx (btw I like the 
name) might not work with some tools, which expect certain suffixes?

R3 is cross-platform, and cURL is cross-platform, but both require 
a little work to make the platform distinctions go away. POSIX helps 
with this on POSIX platforms, but that's not everything. You can 
do a little extra work in your extension to make it work the same 
externally, so R3 code can't tell the difference, but if you want 
that to extend to filenames then you have to pick a cross-platform 
filename standard. Once the extension is loaded, embedded or delayed 
it can be referred to by module name. We don't want IMPORT to grab 
extensions in its module-paths lookup because that would make it 
possible to load an extension when you were looking for a safe module, 
so .rx and .so files aren't going to be in the search list unless 
your program sets system/options/default-suffix to .rx or .so, with 
the same security implications.

Yes, and literally the only platform distinction is the file extension

I am fine with explicitly specifying an extension, just not with 
a forced file extension. How about IMPORT/EXTENSION ?

Do you have a problem with making an embedded delayed extension that 
loads cURL dynamically when the extension is imported? This is supposed 
to be possible, and is the main reason for delayed modules and extensions. 
Then only programs with Needs: [curl] would initialize curl.

Yes, I have a problem with that. It's way too much work for making 
a file extension dynamic, and it breaks most of my use cases

There are many platforms that use the same file extensions, so you'll 
have to find a way to put the BSD .so files in another directory 
from the Linux .so files. The .rx extension just adds Windows and 
OSX to that.

That's merely a problem of organising download directories

I'm sorry that you got used to loading extensions without needing 
to turn off the security restrictions in R3. If it helps you to know, 
you can also specify modules to import on the command line, or put 
your platform-specific delayed module loads in %rebol.r.

%rebol.r is sort of an addon to the host code.

The security setting is not the issue here

The common use case is a modular operating system. You have a standard 
R3 installed. During the life of the system, you install new extensions 
and programs. R3 makes the extensions be operating system dynamic 
libraries and lets the OS look for them, so they must be installed 
in the OS. You don't want to also have to embed each new extension 
in a new R3 binary. You want to install and write separate REBOL 
scripts that load these extensions, and you want those scripts to 
be cross-platform, because they easily can be

So, you want to make a modular OS that has all dynamic libraries 
be R3 extensions natively - LOAD-EXTENSION won't load arbitrary libraries, 
just extensions - and you want the library filename suffix to be 
something other than .rx. OK.

LOAD-EXTENSION doesn't do lookup beyond the current directory, so 
if you want to have it use some library path you have to add that 
in the host code, or %rebol.r. Either way you can add extensions 
and modules programmatically to the R3 runtime before the script 
you're running starts. If you want your scripts to be cross-platform 
then you probably shouldn't use a platform-specific file extension 
for the files, but if they are loaded or delayed in the host code 
or %rebol.r then it wouldn't matter.

What's the problem? Even in R2 I was using code like:
	lib_ImageMagickWand: load/library either system/version/4 = 3 [
		%/c/utils/ImageMagick/CORE_RL_wand_.dll
	][	%/usr/lib/libMagickWand.so ]

I prefere to have this under control. The location may differ on 
different platforms.

For that matter, code like that can go in %rebol.r and then scripts 
won't have to even know that an extension isn't a regular module, 
as long as the API matches what they expect.

Oldes, R3 has decided to let the OS find an extension as a native 
library. I really don't want to override that and write my own loader 
in every script

Are you saying that on Linux and/or Syllable LOAD-EXTENSION looks 
up the extensions in the system library path? Weird.

Not weird, nice :-)

You may want to review my documentation for the cURL binding