[REBOL] .net Framework Re:(2)

[petr . krenzelok]

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: [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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