[REBOL] Re: serious proposition...WAS: RE: Standards
From: nitsch-lists:netcologne at: 7-Nov-2003 7:30
Hi Maxim,
Am Donnerstag, 6. November 2003 23:36 schrieb Maxim Olivier-Adlhoch:
> Well,
>
> I'm sort of scared of letting it out of the bag, but here is a complete
> answer.
>
> I'd like an OFFICIAL, community blessed library/module standard.
>
Thats there. download script to folder, do it.
> Some of you are aware of my idea, some have even tried the ancestor of the
> new tool, steel's open-library function...
>
> The new tool is an object. It makes creating modules even easier and is
> also more mindfull to the rebol way of thinking, as it uses the rebol
> header as the library's header, for example.
>
> I still have no official name but librarian, liberator, modulator,
> moderator, vault, rock, libman top the list.
>
> basically, it supports versioning, reloading, recycling, direct from net
> uploads installation, even should have the setup ui built-in. Softwares
> will also be able to interact with the installation and setup of the
> library on that user's machine.
>
Sounds complicated. Where are the benefits? If i use tools, they are either
inbuild, short snippets which i patch or standalone scripts/directories when
its more complicated. Scripts without dependencies. That works well with the
most complicated scripts i have seen.
> The spec itself really isn't restrictive. actually the base object of any
> library currently has no mandatory attributes or methods.
>
> some will say that there are security issues... I AGREE, and this should be
> reduced once the plugin architecture is available. But then again, any
> module architecture, by definition, implies a security breach. Its a
> question of trusting the source of your tools. If you don't want to use
> the default librarian tool, at least you could adhere to its api and then
> any one who wants to share or use code, has a common method of using it,
> whatever the loader he uses.
>
There are different levels of security risks. Autoupdate is a lot riskier then
downloading a script, inspect it and the source, agree and use exactly this
script all the time. Can i be sure the sources i trust
today will not be hacked tomorrow? And auto-downloaded?
Loading a lot of unneeded libraries automatically is a risk to. Lot more
places for holes. Better to know what goes in the image IMHO
> This helps us to progress instead of turning in circles. IF a master list
> of peer-reviewed libraries comes into existence (THIS is my goal), then we
> will be able to increase the code base as one community.
>
If we increase the code-base we increase the entry level of knowledge, at
least subjectively. Users of large libraries slowly realise they write some
code faster themself then to lookup help forever to do it with
library-functions IMHO. Rebol follows the "if it can be done with some code,
dont wrap it in a library. If you make a library, only if a lot more can be
done with some code then." IMHO, and i like it.
> Not as a group of individuals.
>
> my hope is that a central server (hey that sounds like rebol.org ;-)
> would have a depository of all personal/beta/rebol patch/master modules for
> all of us to use. instead of having several sites to follow for specific
> tools, we could all just dump our libraries at one place and those which
> are peer-reviewed, get "official" blessing by the whole community.
>
Carl said "keep all in one script and no dependency hassles" for rebol.org
IIRC.
> Any bug, any tweek can be suggested on this list (or another), and
> debated. The author or manager of any library is then able to integrate
> it. If it is an "official" library then a "higher-order" workgroup of
> dedicated fellows are all allowed to put in the change, when they have
> time.
>
Usually contacting the Author directly works pretty well. After all, he knows
his code. What would a debate bring? Making PDF-Maker better by adding
wishes? If an Author needs feedback, he can ask here.
The Art of Rebol is: all fits together, all works similar. (Is the magic word
synergy?) Thats different to other philosophies about implementing lots of
user-wishlist. the users have a harder time to find the right functions then.
> I'd be the first one to volonteer as an updater, as long as a real working
> group is built and I'm not expected to be a community servant.
>
> The basic advantage of a master library directory is that it would enforce
> backwards-compatibility, and takes care about the contents, safety,
> performance and future. This makes all of us accept a tool as stable, and
> in turn, allows us the chance to assume and be relax of any of those shared
> tool we would use. It also makes it easier to continue development on any
> tool for which the author disapears or for which times keeps him from
> integrating all the good ideas we all have about everything.
>
If you want backward compatibility, don't change the script. Or use lots of
wrappers to keep apis abstract. MB MB MB. Lots of code to understand. Change
the behavior of a face for example. if possible at all.
> I'd even see RT collaborating, if they wish, to stress-test some ideas or
> view the public's reaction to future ideas without having to distribute and
> commit to official new beta releases... many of the new things just are
> new/changed rebol functions...
>
I disagree. if RT wants to experiment, they have to make sure they can throw
the stuff away. Freezing dependencies somewhere in a large library is the
wrong way then. Putting it in a library sets standards.
> They could also either share some information about future orientations,
> and bless some initiatives, if they feel they complement some of their own
> plans, instead of staying in the dark.
>
> I mean, if I'm going to build a stable glass release and they think its
> enough of an advance, for example, that VID 2.0 is less of a pressing
> issue, they might shift to improving view itself, supporting stuff like
> 2d/3d OpenGL.
>
Why do you need all this library-smartness for glass? why not just giving a
script (or directory of scripts), say "do it, and here is the docu"? Having a
internal scheme for a large tool is ok, but why force different libraries to
work the same way? IIRC some people had problems with your librariomatic,
which may have affected testing? And, please, stay out of %user.r. thats
private array i want full control over. ;)
> I know the idea of all of us agreeing to one thing is a hard to forsee
> project, but I really feel we are at the point where such a concensus is
> essential for the growth of the "platform". I am also one to think that RT
> cannot plug all holes. Such a community acceptance would allow them to
> relax on some stuff that we all want, we ARE capable of doing many things
> ourselves. We already have.
>
They can not plug all holes anyway. simply because people want to use other
software they are used to, have to use etc. They can plug some holes very
well. also holes in this software. like distributing. And rely on peoples be
smart enough to rely on standards for documents.
> I'm sure many of you don't agree on the usefulness of what I am proposing,
> but other languages have benefitted by this and I feel rebol is another
> which would.
>
Rebol thinks this languages have failed because of such features AFAIK. Lots
to complex. Rebol does the same without it. Instead it gives us the ability
to do most stuff in 50K. so there is not so much to organize and version and
download and discuss etc.
Regarding failing, these squeak-guis had some experience with similar concepts
lately. trying hypersmart declare-everything strict-structure modules. Now
they have squeakmap instead, which is basically "download script and drop
into image." everyone understands, works pretty well.
> some the above might sound extreme, pretentious, harsh, useless,
> controling, whatever. It isn't meant as such, if that's how you read it...
> its just someone wanting to make things move in a good hearted matter...
> and sometimes, more opinionated language stirs more discussion...
>
Me is overracting too ;) Everytime someone tells me Rebol is not complex
enough ;)
> :-)
>
> cheers! :-)
>
> -MAx
Cheers,
-Volker
> ---
> "You can either be part of the problem or part of the solution, but in the
> end, being part of the problem is much more fun."
>
True. But sometimes avoiding the problem is better. More time too choose
problems with more fun ;)
