World: r3wp

Earlier in the session of the call to the interpreter. When the program 
starts it loads the extensions and modules it needs. If you need 
to load things from specific filenames, do that before you load the 
other code. The module system is designed to help you organize and 
manage the code in a program.

I really don't want to load all extensions in the system on all days 
of the week. Just like I don't load the thousand libraries in a Linux 
system into every program (well, almost, but that's the gruesome 
consequence of this going wrong)

Sorry, wrong system. I mean loading extensions into the program, 
not the operating system.

That was just an example. I do mean the R3 system

Is the module system meant to manage the code in a program, or the 
code in an entire operating system?

Just in a program, not the OS. Each program loads its own modules 
and extensions. Unless R3 *is* the operating system.

Then the program has a problem with portability due to different 
file extensions on different operating systems

You can use different IMPORT blocks depending on the OS, in the same 
code. The highest-level script is usually a not a module, so you 
can call IMPORT directly. Then your modules can just do their requirements 
by (word) name instead of specifying filenames.

But the .rx filenames are supposed to make things easier, and will 
for many OSes.

Exactly, so every program needs to test on which OS it runs and execute 
different IMPORT branches. So why not pull that into IMPORT itself?

IMPORT uses the OS's dynamic library loader, which searches through 
the system's locations where libraries are registered. So you install 
R3 extensions there, in the system. If you use .rx extensions, they 
will be the only ones, awkwardly between lots of .so files on POSIX 
systems and lots of .dll files on Windows

For one thing: system/options/default-suffix. For another thing, 
platform-specific stuff doesn't go in the mezzanines, it goes in 
the host code, as a (really strict) rule. For most code that needs 
extensions there is assumed to be a bit of platform-specificity, 
due to the nature of extensions. Nonetheless, this is why LOAD-EXTENSION 
is implemented in the host code, and why we can reference functions 
by word name.

I don't care if the implementation is in mezzanine or in the host. 
My question was if IMPORT can look for .so on POSIX and .dll on Windows?

Also, look at system/options/file-types. You can find the file extensions 
that are loaded as R3 extensions, and then go through them, adding 
them to your file's base name to find your file. Or you can add a 
one or two line platform-specific wrapper for your module code.

default-suffix is .reb and that is meant for a mezzanine module, 
not for an extension

file-types contains "%.so extension" so we're halfway there, but 
IMPORT doesn't act on it

You don't want IMPORT to do automatic lookup for more than one file 
extension because it's a potential security hole. For that matter, 
you should know if you're loading an extension instead of a module, 
because extensions could break the rules that REBOL source modules 
can't. And system/options/default-suffix can be set by your program. 
For that matter, the host code for LOAD-EXTENSION could translate 
.rx to .so on platforms that require .so and won't load .rx - that 
is a platform-specific restriction.

That's why I don't want to use .reb for extensions

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.