Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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-