[EMAIL PROTECTED] wrote:
> >Just a note - isn't it too late, if two books on REBOL are already finished?
> >Elan, Ralph? :-)
> >
> >-pekr-
>
> Not too late, if solution is implemented correctly. Since the strength of
> Rebol is dialecting, then we should maintain backward compatibility through
> dialects. Rebol/Core 2.x scripts would not break if there was a "2.0
> dialect" included with Rebol/Core 3.x.
>
Would be a kludge but why not if we would gain by such change?
> RT needs more staff and money, so Core team can focus on philosophical
> issues, and special task forces can focus on integrating Core with other
> technologies (Graphics = /View, OS and Databases = /Command, WebServer =
> /Apache).
Exactly. IIRC those were the words of someone from RT - there are many issues
that could be implemented/refined for /Core - so why to shut it down and
concentrate on higher level eye candy? I think "true rebollers" would be much
more interested in things like /shell and /library becoming native part of /Core
- so free, tasking/threading, ability to link two even remote rebols thru system
object (e.g. system/family, if we have faces, feelings, etc.) Wouldn't it be
great?
Current aproach of everything-in-one-exe is advantage, but how long for? I hope
we will see some /Math, /Draw, /Whatever in the future. I don't think there is
the reason to stop ourselves at current point. It would mean just one thing -
death to rebol. I know there is time you have to go out with what you have, then
sort your thoughts, and make a next logical step. I would like to believe Carl
will balance RT's current marketing aproach (just-one-file philosophy) with
request of let's say majority of opinions expressed here - so modularity,
granularity, openess, etc.etc....
RT folks are silent, but carefully watching us .... Just a little test .... heya,
Jeffy, I like your long hair ;-)))
> By overcoming implementation challenges, the task forces gain knowledge
> that they can bring back to /Core that will empower RT to overcome new
> challenges when integrating into other technologies (imagine
> multiprocessing = /Beowulf, Home Automation = /Base, streaming media and
> telephony = /Yell)
>
> But the real money may be in business-to-business. Imagine your company has
> developed an incredible software product whose functionality can be
> extended through use of a C API. Users would much rather have an easier
> means than going through a write-compile-test cycle to extend the product's
> functionality. If Rebol was integrated into the product, then user
> productivity would skyrocket.
> Case in point, Remedy Corporation has a workflow product called Action
> Request System (ARS). The 2 means of accessing its power are through a GUI
> and the ARS C API. At the State University of New York at Buffalo, users
> created ARSPerl, a perl module that encapsulates the function of the Remedy
> ARS C API. To my way of thinking, they turned to Perl because RT wasn't
> there to save them. What other opportunities might RT missing?
Yes, we are building CCD camera and I still think our main app will be created in
rebol, supplied by modules in native libraries. We will not create scripting
environment for some Delphi, VB, C++ project, as we will be complete glue
technology powered by rebol - complete freedom in user environment creation ....
(we will just need some specific /View and /Command functionality, but I am not
so far yet ...)
Cheers,
-pekr-
