[ALLY] Re: /System
From: petr:krenzelok:trz:cz at: 27-Oct-2000 22:00
----- Original Message -----
From: Elan <[rebol--techscribe--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
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
> 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