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

[ALLY] Re: /System

From: petr:krenzelok:trz:cz at: 27-Oct-2000 22:00

----- Original Message ----- From: Elan <[rebol--techscribe--com]> To: <[ally-list--rebol--com]> Sent: Friday, October 27, 2000 9:32 PM Subject: [ALLY] /System
> Hi guys, > > sorry to bring this up, but it is a practical problem right now. I have > as much as convinced a client that we should implement the GUI interface > of his application in REBOL/View instead of using HTML. This decision > would cause us to replace PERL and HTML by REBOL/View. My problem is that > we must also launch programs that provide special services, such as > paging. As soon as I say that this part of the functionality will have to > be handled by /Command or PERL, the customer (this one happens to be a > PERL hacker himself) snaps back at me saying, well then lets do all of it > in PERL. Forget /View.
I of course don't know the kind of application, but if you are on the server, you can use CGI, or what about using javascript in browser? Does it allow to start apps? And if not, what about some kind of mime type registered to browser to launch the related app? Of course I don't know if any of above would work ... Then there's another solution - let's implement some "standard" C based app (gate), listening to rebol on one side, launching commands on the other side. IIRC such solution was provided some year or more ago on rebol ml. Launching of externall apps is matter of one or few lines of code in Delhpi e.g., or not? and btw: what's bad with external environment launching the app? Unix land is full of utils sending output one to many others, so what ;-) btw: does perl have any default gui environment? Or do Perl users use tcl/tk?
> I could imagine that this may be an attitude that comes up frequently, > and that may stand in the way of REBOL's acceptance by the scripting > community. How much work would it be for you guys to release a /Command > /View combo? Single executable that includes /Command as well as /View > functionality. Once /View has stabilized to the point where there is a > /View stable release, the /Command /View combo (/System ?) could be > launched as an upgrade for /Command users who require GUI functionality. > > What do you think?
Elan - no way - if we will go that way - we are doomed. Who will handle all that variants? What if I want another component? There is only one way - proven already very well in computing - to have a kernel /Core, and dynamic loadable components (libraries, devices, call it whatever). Only that way makes sense and I know RT knows that's the way to go. Carl likes modularity, as he created AmigaOS. I think RT just don't have the time to abstract the solution nowadays, as it would require to isolate components internally and set some kind of APIs. But having just /Core and being able to buy just components I need is so cool - even for RT, as it allows them to ask for more money that way .... if someone is going to buy /Oracle, you can bet the company can afford some hundreds of dollars price, because the company owns Oracle based server :-) Having everything in one .exe is limiting everybody ... Cheers, -pekr-