[REBOL] .net Framework Re:(2)
From: petr:krenzelok:trz:cz at: 10-Sep-2000 21:45
This is a multi-part message in MIME format.
------=_NextPart_000_0029_01C01B70.752C52A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
The question about /View inclusion into REBOL/Command is not confusing only you. I have
asked the same question for several times but got no answer. I think it has something
to do with RT marketing strategy, which couldn't be fully defined in the time I asked.
It's more general question than most of us could think imho. The topic of REBOL modularisation
was discussed here some time ago but with no clear answers too. I don't want to start
it once again here, but a small conclusion of what we know in the case you are relatively
new to the ml .....
- Carl outlined some future plans which contained something like "on demand component
loading". As /View is "just" a component (e.g. you can find it in system/components listing),
it would be logical we should be able to just load /View into /Command. The reality is
just different, but on the other hand /Command is still in beta.
However, RT expressed component plug-in system doesn't work for them and it has to do
something with the marketing or I just can't understand it. There was several solutions
offered by folks on ml. E.g. - moving /library and /shell components to /Core capabilities
and charging for RT own library extensions .. or ... making just one and only executable
- core - kernel, and everything other in the form of plug-in, components, libraries,
whatever (there was opinion against it, RT thinks "just one file" means some marketing
advantage and easier end-user setup). Somebody even came up with choose-your-component-and-pack-it
system thru website (e.g. choosing just /shell and /library, but no /ODBC if I don't
want to use it, and obtaining rebol.exe with packed in components), if there is desire
to have everything molded into one executable ....
It's very easy to jump into some conclusion however. I think we are near REBOL commercial
product release now - /Command, /Express. Let's see what RT will come up with and let's
see if their policy will meet our expectations ...
... as for me - I have some doubts however. As /Core doesn't have library or shell access,
we have /Core based /Apache and it means no database access. We have /Command, but then
we have to use CGI and we all surely know reaction of those making dynamic websites :-)
The solution doesn't have to be free, but they will not consider leaving PHP if the thingy
is not Apache module.... On the other hand - we will get complete e-commerce suite -
REBOL/Express. But it doesn't mean we sure ignore general web techniques too :-)
There's more to the topic, but let's say - I never run company so I can be of course
wrong. What's more - I would like RT strategy to prove me being wrong ... :-)
REBOL long time supporter,
-pekr-
----- Original Message -----
From: [rishi--picostar--com]
To: [list--rebol--com]
Sent: Sunday, September 10, 2000 8:28 PM
Subject: [REBOL] .net Framework Re:
I agree rebol has to be platform independent as possible. But I also think rebol has
to be as flexible as possible. It should be able to mold itself to work with a specific
platform if the user wants. Platform dependencies open up a whole new world of what rebol
could do and used for. The key is flexibility. REBOL shouldn't fall into the same trap
java fell into by trying to be a self-contained language and platform in a world by itself.
Just like dialecting is context specific, rebol should have the capability to be platform
specific (and obviously platform independent). Hopefully Rebol Inc. already realized
this and will incorporate this thinking in REBOL/Command.
By the way, will REBOL/command include rebol/view (which includes rebol/core). Or do
you need to have rebol view installed before you can use rebol/command? A bit confusing
to me....
Anyone know if Rebol technolgies will be porting rebol/view, rebol/command to qnx real-time-platform?
Rishi
------=_NextPart_000_0029_01C01B70.752C52A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.2614.3500" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face="Arial CE" size=2>The question about /View inclusion into
REBOL/Command is not confusing only you. I have asked the same question for
several times but got no answer. I think it has something to do with RT
marketing strategy, which couldn't be fully defined in the time I asked.
</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Arial CE" size=2>It's more general question than most of us
could think imho. The topic of REBOL modularisation was discussed here some time
ago but with no clear answers too. I don't want to start it once again here, but
a small conclusion of what we know in the case you are relatively new to the ml
.....</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Arial CE" size=2>- Carl outlined some future plans which
contained something like "on demand component loading". As /View is just
a
component (e.g. you can find it in system/components listing), it would be
logical we should be able to just load /View into /Command. The reality is just
different, but on the other hand /Command is still in beta.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Arial CE" size=2>However, RT expressed component plug-in system
doesn't work for them and it has to do something with the marketing or I just
can't understand it. There was several solutions offered by folks on ml. E.g. -
moving /library and /shell components to /Core capabilities and charging for RT
own library extensions .. or ... making just one and only executable - core -
kernel, and everything other in the form of plug-in, components, libraries,
whatever (there was opinion against it, RT thinks "just one file" means some
marketing advantage and easier end-user setup). Somebody even came up with
choose-your-component-and-pack-it system thru website (e.g. choosing just /shell
and /library, but no /ODBC if I don't want to use it, and obtaining rebol.exe
with packed in components), if there is desire to have everything molded into
one executable ....</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Arial CE" size=2>It's very easy to jump into some conclusion
however. I think we are near REBOL commercial product release now - /Command,
/Express. Let's see what RT will come up with and let's see if their policy will
meet our expectations ...</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Arial CE" size=2>... as for me - I have some doubts however. As
/Core doesn't have library or shell access, we have /Core based /Apache and it
means no database access. We have /Command, but then we have to use CGI and we
all surely know reaction of those making dynamic websites :-) The solution
doesn't have to be free, but they will not consider leaving PHP if the thingy is
not Apache module.... On the other hand - we will get complete e-commerce suite
- REBOL/Express. But it doesn't mean we sure ignore general web techniques too
:-)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Arial CE" size=2>There's more to the topic, but let's say - I
never run company so I can be of course wrong. What's more - I would like RT
strategy to prove me being wrong ... :-)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Arial CE" size=2>REBOL long time supporter,</FONT></DIV>
<DIV><FONT face="Arial CE" size=2>-pekr-</FONT></DIV>
<DIV> </DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT:
5px; PADDING-RIGHT: 0px">
<DIV style="FONT: 10pt arial CE">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial CE; font-color: black"><B>From:</B>
<A href="mailto:[rishi--picostar--com]"
title=[rishi--picostar--com]>[rishi--picostar--com]</A> </DIV>
<DIV style="FONT: 10pt arial CE"><B>To:</B> <A href="mailto:[list--rebol--com]"
title=[list--rebol--com]>[list--rebol--com]</A> </DIV>
<DIV style="FONT: 10pt arial CE"><B>Sent:</B> Sunday, September 10, 2000 8:28
PM</DIV>
<DIV style="FONT: 10pt arial CE"><B>Subject:</B> [REBOL] .net Framework
Re:</DIV>
<DIV><BR></DIV>
<DIV><FONT face=Arial size=2>I agree rebol has to be platform independent as
possible. But I also think rebol has to be as flexible as possible. It should
be able to mold itself to work with a specific platform if the user wants.
Platform dependencies open up a whole new world of what rebol could do and
used for. The key is flexibility. REBOL shouldn't fall into the same trap java
fell into by trying to be a self-contained language and platform in a world by
itself. Just like dialecting is context specific, rebol should have the
capability to be platform specific (and obviously platform independent).
Hopefully Rebol Inc. already realized this and will incorporate this
thinking in REBOL/Command.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>By the way, will REBOL/command include
rebol/view (which includes rebol/core). Or do you need to have rebol view
installed before you can use rebol/command? A bit confusing to
me....</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Anyone know if Rebol technolgies will be
porting rebol/view, rebol/command to qnx
real-time-platform?</FONT> </DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Rishi</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0029_01C01B70.752C52A0--