[REBOL] Re: REBOL/Contrib
From: petr:krenzelok:trz:cz at: 23-Nov-2000 16:20
nop wrote:
> Hello, folks:
>
> If I may, I'd like to mention a thing or two about the contrib system:
>
> o As the contrib web page says, all submittal code goes to
> [contrib--rebol--com] and all the paperwork HAS to be sent along as well
> for the code to be considered. It's just a business reality.
>
> o We can't promise anything, to anybody. We're likely to turn
> down much, and that's because REBOL has a ridiculously high
> standard.:)
>
> o We also can't promise to be fast. But if you do send in code to
> contrib we do promise to give it our attention.
>
> o Volume of submissions has been low. Why??
Because of level of advancement? Can we advance REBOL by contributing
source codes? I like every kind of advancement, everybody does :-) But to
be honest, I think most ppl are expecting advancements in the rebol
technology itself, but can we help it? RT representatives read all the
mls so you folks surely know what bothers us. RT says they hear our
voices, but nothing is being done about it (or we just don't know
something is being done), and other things (REBOL/Express) seem to have
higher priorities ...
Let's face it:
- Apache based upon /Core. You are on Apache ml Jeff, so you surely
remember our complaints about it - no database access ....
result: beta product
development: postponed
- /View - I try to use /View for last few weeks as much as time permits,
and I have to say - you guys deserve medal. It's a great concept. But:
result: beta product, some bugs, RT was already asked for full release
development: slowed down, last few months updated mainly at /Core level
- /Command - I last used beta version, but - for the capabilities it
offers, comparing it to other systems - still overpriced, and unfeatured
....
conclusion:
As you can see, I don't use 'result and 'development item for description
here, as I think current /Command model is wrong. We really need dynamic
components, and because we don't have it we suffer in following way:
- without component model, we have to wait for RT to produce "endless"
variations of products ... RT was already asked for Apache/ODBC/Database
combination, /Command/View combination, I also expressed the need for
/Core/Shell combination etc. There should be only one rebol/core. Not few
incompatible versions thru various products.
- rebol community can't do anything about the state of things. At least I
am glad RT marketing ppl agree that dynamic component model is good way to
follow, as it allows to raise/lover prices (e.g. why to sell /Oracle
component for few bucks, if someone who has already paid for such big db
as Oracle is, can afford to spend much more money for the component ...)
Other possible advancements:
- parser advancements were submitted more than year ago? parsing to/thru
first match from several (e.g. to [op1 | op2 | op3]), 'replace in parse
level, parsing upon opened ports)
- /dir and /files refinement to 'load to prevent us from manually sorting
block of dir items, and could possibly speed up file-requestors upon
larger directories
- find/flat, or find/deep - would perform the search in a series,
regardles of structure - would return series in the point of where the
value is foud. Imagine deeply nested XML parser resulting block:
->> block: ["a" ["B" "C"] ["E" ["F"]]]
->> pos: find/deep "F"
[3 2 1]
->> tmp: block
== ["a" ["B" "C"] ["E" ["F"]]]
->> for i 1 (length? pos) 1 [print tmp tmp: pick tmp pos/:i]
a B C E F
E F
F
== "F"
Hmm, I am not sure it makes sense :-)))
- some slight improvements to View (hiding mouse - then we can come up
with own faces for mouse), maybe even Allen's suggestion for native menus
and slidebars to windows ... good for some fast prototyping of production
apps with native OS look...
- native matrice operations to produce faster effects upon images, but
usefull for other stuff too ...
- would it be possible to define some kind of API to allow working upon
REBOL datatypes from external environment? E.g. calling library function,
sending it rebol loaded image (which is stored in block), and manipulating
the data in the library level ...
- modules proposal Carl introduced some half year(?) ago to ally list
members
- more direct link to external environments? It's a shame REBOL Toolkit
was cancelled. (well, it was mentioned only in one very early /Command
announcement), but there would be interest in such product ...
As long as some ppl will think e-commerce saves the world, as long we will
loose .... :-))
Carl asked us for help. OK, yesterday I finished article for our premiere
programmer's mag. I am just scared that after the readers will look at
rebol from the same perspective I expressed above, they will leave us
soon, and will not come back. We can't spread rebol, if we are
contraproductive (e.g. Apache situation), and yes, I tried it with several
very good friends. Although they listened carefully, REBOL lacked
important features at the area given (database connectivity) ...
I thought we want to become universal glue for various environments, but
we are not there ... not yet, not yet, but we surely will, but you know -
when
? :-)
Cheers,
-pekr-
