[REBOL] Re: About View
From: petr:krenzelok:trz:cz at: 28-Mar-2001 21:38
----- Original Message -----
From: "Carl Sassenrath" <[carl--rebol--com]>
To: <[rebol-list--rebol--com]>
Cc: <[ally-list--rebol--net]>
Sent: Wednesday, March 28, 2001 8:30 PM
Subject: [ALLY] About View
> About REBOL/View... funny that you ask, because:
>
> The REBOL team held a three hour meeting yesterday to discuss REBOL/View
and its future. We came up with an excellent solution that provides a free
version of View that is upgradable to a professional version that includes a
few additional components, such as command shell, library access, and
encryption.
> The demand for such a product seems high. We get a lot of email from users
who want it. Of course, our hope is that all of you will want to buy the
View/Pro product. And, that you would convince your friends, companies,
comrades, and neighbors to buy it too. We need that to happen! Tell
everyone.
> I should point out that REBOL/View is not REBOL/Link. There would be no
auto-sync, Serve side, desktop, installer, etc. But, it does provide a
solid 1.0 for you to rely on. It would be official... and no more
expiration woes.
> Unfortunately, I cannot provide more detail at this time. We are still
planning it out. However, if the decision is to proceed, we would release
View/Pro 1.0 in less than a week.
> Please let us know your thoughts.
I thought strategy here is clear? - Rebol/Link/World will replace current
Rebol/View .... is it really needed to produce so MANY variants? The problem
is I simply don't/can't believe you will keep them all up to date ;-)
History back-ups my opinion ....
As even for current View I wondered what one could do to remove View panel
related code. I don't know how much size it adds to Rebol/View itself, but
in most areas of usage it is not necessary and it could easily live in an
external script form. We are mixing several layers here - core product (C
level code), supporting functionality (rebol functions, VID dialect) and
area respective/supportive code (View panel code). The third layer should
not be hardwired into rebol imo. It messes global name-space (we don't have
modules/components yet) and is not of a general use. On the other hand -
View panel adds value to Rebol community, as it server as global
word-wide-reb and Serve - Link goes even beyond. The question is - do we
need it inside?
Release one View-like product only - called View or Link/World, whatever,
being able to connect to Serve _upon_request. e.g. by typing "help" or
demo
. Couldn't it live in external file? The first rebol component, eh?
;-) Because that way, you also save your resources, as why to re-release
View for e.g., just because there is some bug in View panel? ;-)
We don't have components, so we should be carefull to don't release tones of
uncompatible products. As you can see - in current situation - everyone is
going to be confused about what is part of what, why this is not part of
that, etc. Just don't forget the consistency factor, please ....
possible products:
core - core/pro
view - view/pro
Serve - Link = Express family, special functionality allowed ...
/Runtime - for all
/Apache/pro
/Command - View/Command
starting to be confused :-) What if someone wants Link Express client being
able to access local system libraries, shell, or even databases? Will we
produce Link/pro, or even /Link/Command? :-)
Thanks,
-pekr-
