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

[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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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&nbsp;in REBOL/Command.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV> <DIV><FONT face=Arial size=2>By the way, will&nbsp;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>&nbsp;</DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=Arial size=2>Anyone know if Rebol technolgies will&nbsp;be porting rebol/view, rebol/command to qnx real-time-platform?</FONT>&nbsp;</DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=Arial size=2>Rishi</FONT></DIV> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0029_01C01B70.752C52A0--