World: r3wp

It's not hiding. Most of the executable file types on Windows are 
really DLLs, including .dll, .exe, .ocx, .vbx, ...

Is there any harm in allowing .rx alongside with .dll .so and .dylib?

We need it on Windows so we can make a .rx wrapper for a .dll third-party 
library.

With both .rx and .dll having the same name? OK.

The harm comes from having .dll, .so or .dylib in the Needs lists 
of what would be otherwise portable REBOL modules and scripts.

Would only be portable, if there are ported versions of the extension 
they are needing

So if you only have a .so version of your extension, using Needs: 
%foo.so has no harm done

It's better to not have .so in there at all. Part of the design strategy 
of the R3 language is to at least pretend that the language is portable, 
and keep all of the non-portable stuff wrapped in extensions or hidden 
in the host code.

But realistically there will be loads of purpose built non-portable 
extensions

And as allowing them to be used with their native extension does 
no harm as far as I can tell, I'd enable that usage alongside the 
.rx

Doesn't negate my argument. Having them named .rx will mark them 
as extensions, which have a specific calling convention that must 
be supported. Nonetheless, if you do decide to also allow the default 
platform dynamic library naming convention, only allow the name supported 
by the current platform. So no .dll on Linux, no .so on OS X, no 
.dylib on Windows.

Sounds like needlessly complicating the code

.so is correct on osx

simply marking rx/dll/so/dylib as possible extensions for extensions 
sounds perfectly reasonable

Not needlessly - .dylib files don't work on Windows.

Yeah, but who cares?

They even might, if someone wrote a dylib loader for windows

We do. Simplifying the code would be to just support .rx and have 
the LOAD-EXTENSION native in the host code do the translation.

Go for it, then

I'd add some nice magic for .rx

And keep .dll .so and .dylib as they are now

If some use desperately wants to use .dylibs on Linux, I don't care

some user*

I want to keep .dll, .so and .dylib files as they are now. That is 
what we write .rx extensions to wrap.

But a .rx is nothing but a .so

No, it's a .so with a really specific set of exported functions.

Yes, the definition of a dynamic library

If you want a single platform extension: name it foo.so, use it with 
import %foo.so; if you want a multiplatform extension: create libraries 
foo.so, foo.dll, foo.dylib, import with %foo.rx

Sounds reasonable and simple to me

It's the same as .ocx or .exe files on Windows - what matters is 
the specific functions they export. All .rx files export the same 
functions.

That's fine, but they will still be platform specific binaries

But whatever

So what? There's no reason why dynamic libraries should be called 
.dll on Windows and .so on Linux, none at all.

Go for .rx, fine with me

If you add a capability to ship multiple libraries easily, that would 
be great as well

I.e. that i can ship linux, windows and osx extensions along with 
a simple script, and use the proper extension on the proper platform

Universal Binaries or some such?

nope, just simple namespacing issues

if all three extensions ought to be called foo.rx, shipping them 
side by side will be tough :)

There are many platforms that use incompatible .so or .dll files, 
so a packaging/installer format would be good.

yes

the nice thing about my patch: it would enable linux extensions _right 
now_

letting people play with them

We aren't just supporting 3 platforms.

currently you the hostkit supports only 2

i like small, incremental changes

No, it wouldn't because LOAD-EXTENSION doesn't work on Linux yet.

load extension works great on linux

Check if it works with .rx named files, I'm curious.

$ file ext/sample.so 

ext/sample.so: ELF 32-bit LSB shared object, Intel 80386, version 
1 (SYSV), dynamically linked, not stripped