World: r3wp

That's true, but it's not tied to the name, Brian tells us

True. You would use a different file for Linux, though it could also 
be called %zlib.rx :)

I admit I confuse people by violating this truth and running the 
Linux binary on Syllable :-)

But than I need zlib.dll and zlib.so in the folder.. and what if 
I don't have zlib.so yet?

Since they don't work on both OSes, you wouldn't install them both. 
You install the matching one under the same name

Then don't have zlib.rx in that directory either :)

What is content of zlib.rx?

The R3 extension wrapper for ZLib.

that's the zlib.r3 for me.

Or the R3 extension that statically links ZLib if you like.

I don't get it.. I will wait for real life example..I'm fine how 
I have it now.

In your case you could just rename zlib-rxt.dll to zlib.rx and it 
would work.

And it will work on Linux?

You would then import %zlib.rx instead of %zlib.r3. It would work 
on Linux if you made a Linux build of zlib as a R3 extension and 
also called it zlib.rx.

But I want to make clear that the file is DLL, not SO.

maybe I will need my extension on linux later so I will make the 
SO, and I want both in the same directory, not just one, which I 
use at this moment. I want to have my files structure platform independent.

Why? Don't you put other platforms' extensions in different directories? 
There are multiple platforms that use .dll and .so, remember.

no... I use same structure.

And when you install it you don't need to install other platforms, 
just the platform you're on. So you only install the zlib.rx for 
your platform.

I do not install... I just copy folders. the true is, that now it 
can be more complicated as I have also the C sources in the same 
dir.

never mind... this is just a minor detail. Form me is important I 
can decompress zlib data as I could with R2. That's all.

If I had more time, it would be good to try some zlib/gz scheme.. 
but that's not important for me at this moment.

What is more important - can we UNLOAD the extension?

I thought that was included in R3 now?

You can't unload extensions.

Zlib in R3 doesn't work.

http://issue.cc/r3/1667

Kaj, here's an example %rebol.r for your scenario:

REBOL []
use [sys-path] [
sys-path:  %/some/safe/directory/full/of/extensions/
sys/load-module/delay map-each x read sys-path [sys-path/:x]
]

I have no time to wai for built in zlibt. But for me is every small 
extension a good C exercise

Then you make sure that your extensions can survive being delayed 
:-/

How much time and memory do delayed modules take? In any case, it 
will be too much on for example CGI scripts

BrianH: isn't having just one name going to be a problem for us? 
I like the .rx extension very much. But think about distros. You 
can't have one storage of extensions for various platforms. Dunno 
if such use case would exist. Something like big directory of extensions 
somewhere on the fileshare. In the same path. If the suffixes would 
be different, then those files could co-exist. Hmm, maybe not, because 
.so works for Linux, other Unixes, and those might require different 
extension binary anyway? How would you solve such a case? Subdirs 
per system? e.g. /amiga, /win32, /win64, /linux, /syllable?

Time: not much. Memory: don't know, platform-specific. They don't 
have their source decoded, but the library is loaded (I think), though 
no code is called except RX_Init (from what I gather). I haven't 
done much work with extensions yet but Carl says they work like that.

Alien binaries shouldn't be installed, so you need separate packages, 
or a package with an extension installer. If you really don't want 
to do that, you need subdirectories

A system-wide loader like that is a feature of an OS that starts 
once, not of a language platform that launches many times

Pekr, the idea behind .rx is to make it possible to write cross-platform 
extensions and have them be called by cross-platform code. If people 
are using extensions then they are expected to be importing them 
before they use them. The .rx convention is one way to do this; platform-specific 
loaders is another. Choose what you prefer.

Subdirs per platform is one way to do this (if you are calling your 
app from a network share, or building it from source for instance).

So how about import/extension ?

BrianH: I fear of the following problem - some user thinkining - 
hah, %sqlite.rx, downloads the extension, but the extension is in 
fact only Windows one :-)

Have them download a zip file containing the Windows binaries. That's 
how SQLite does it.

Kaj: No need. You can import the extensions by filename. We want 
the initial import of an extension to be really clear, distinct from 
the import of a module. If you say that LOAD-EXTENSION looks up the 
file in the system library path, that shoul;d be all the searching 
we would need.

Importing an extension has security implications, so it isn't something 
we want to happen by accident. Make it clear by including the filename.

Do you acknowledge my concern at all, even after learning that R3 
uses the OS loader?

I would like to get back to Oldes' quesiton - is unloading extension/module/gui 
or other elements technically impossible?

I mean - once I define e.g. layout, objects get defined, and unview 
just hides the window, but the rest is still in the memory without 
any way to be cleared. Is that even solvable? I have no idea of how 
to track all possible references to be unset :-)

I think it's just not implemented yet... R2 was using FREE to unload 
library.

(sorry to spoil the extensions group for my question, but it might 
be similar)

I don't know. I think that extensions are unloaded when the program 
closes.

Once the program closes is not usefull at all. Think about R3 as 
an OS. It somehow should track resources. And/or stuff like GUI etc. 
should be isoloted in some context which you could easily scrape 
- unset, free, whatever ... or the memory consumption will rise endlesly?

I don't think we are so far (making R3 OS) :)