> === Original Message ===
> 
> 
> > documentation:
> > http://www.rebol.it/~steel/libraries/index.html
> >
> > downloads:
> > http://www.rebol.it/~steel/downloads/
> 
> Thank you !
> 
> SLiM seems to be a very important tool helping Rebol developers to share
> their work more professionally.

that's one of its chief missions.


> However, I confess I still do not well understand what problem SLiM is
> trying to solve...

I know, its a little hard to explain too, without too much examples
laying around.  I'm working on that.  Think of slim as a .dll or .so 
loader and management tool, but for rebol code.  I know you can 'DO 
code but then you can't manage it.  if a tool creator uses a certain
terminology with conflicts then you are forced to recode stuff.

  If he releases a newer version, then any change you made is
then lost.... I know how frustrating it is as I just had to do that 
with an application I am adding functionality too, but I am not the
main author...

 
> I believe you have created a universal object wrapper tool with friendly
> syntax.
> SLiM's chief purpose is to avoid namespace confusion among any programs
> loaded, especially unknown ones.

And to reuse any changes you want to bring to external interfaces.. 
without any amount of code change.  IT actually frees api and
developers the task of trying to find universaly unique names...  It 
empowers the USERS of that api, the chance to adapt IT to THEIR code,
instead of the opposite.

I can see many new features being added to slim.  I have an idea on how to
encompass the file i/o functions to properly TRAP all disk access, 
but that kind of thing takes time to implement and only user demand
can push it, until I have time to get to it, on my time.

Anyone help on slim (asking for features/implenting/fixing ) is gladly
accepted.


> Please can someone provide a concise[dummies/executive] guide to explain
> better why SliM exists?

I'm working on it.  When forge comes of age, slim will be fully
integrated.

also note that SLIM is a tool and an API, but its the actual API I'd like
to be a standard.

if we all package our code in the same way, then we can "EXPECT" it
to be in a certain form.  slim's api is EXTREMELY simple, yet with a
little tool added over it, it becomes very easy to create large 
toolsets with linked files and data.

GLASS is the perfect target for such a thing, it was always meant
to use a tool like slim.  GLASS, as a public release is still
long away, but it will use slim's capabilities fully.

> What is the problem/solution domain?
> ....with illustrative use-case examples if possible.

ASAP.

I'll mainly try to convert all the steel libraries into slim
format... and then give examples using them. 

thanks for the feedback.

-MAx

---------
-- 
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.

Reply via email to