Re: More CGI Stuff
Hi Ruslan, > on 9/1/02 17:54, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: > >> It exists, it just hasn't made it on the site yet. >> Ruslan? > > Yes, Brian, if Dave need it, please send to him YOUR copy of VXCMD > macho > >> Ruslan >> >> Does this mean there is a Mach-o version available now? I don't see >> it on your site. >> Cheers >> Dave > > -- > Best regards, > Ruslan Zasukhin [ I feel the need...the need for speed ] i have an even better idea. Just post this macho VXCMD on your site. This way even people with a license could get hold of it ;-) Thanks in advance... Regards Klaus Major [EMAIL PROTECTED] ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: More CGI Stuff
You can easily use a long-running Metacard stack in the background- just launch it normally and communicate from your CGI using sockets (or any other IAC). Problem is- you can only handle one connection at a time with the long-running stack. That is why I've been investigating using multiple processes with the Darwin engine. Not sure on this one - seem to remember some comments on the list b4 - but not tries it yet... something to do with having MC already running in background on the server (ie not started by a cgi)? Is it then possible for the CGI to start using / send messages to the MC stacks already up and running? This has to be possible via some type of IAC but is the process started via the same as the mc engine running in the background...
Re: More CGI Stuff
on 9/1/02 17:54, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: > It exists, it just hasn't made it on the site yet. > Ruslan? Yes, Brian, if Dave need it, please send to him YOUR copy of VXCMD macho > Ruslan > > Does this mean there is a Mach-o version available now? I don't see > it on your site. > > Cheers > Dave -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] - e-mail: [EMAIL PROTECTED] web: http://www.paradigmasoft.com To subscribe to the Valentina mail list send a letter to [EMAIL PROTECTED] - ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: More CGI Stuff
On Wed, 2002-08-28 at 23:58, [EMAIL PROTECTED] wrote: > Eh! You're right- it does work. It seems I had written off the MacOS engine > for scripts (I've been using the Darwin engine) for other reasons (namely > "open process" behavior). Anyway, externals can be used through scripts just > fine by way of "start using" with the mach-o engine and a mach-o external. > > Of course now I just need a way to maintain some persistent memory (i.e. > database cache). Any ideas? I can write globals to disk if needed, but I > can't afford to re-create the database cache on every run of the script. > Sounds like maybe I need to wait for Valentina Server. > Not sure on this one - seem to remember some comments on the list b4 - but not tries it yet... something to do with having MC already running in background on the server (ie not started by a cgi)? Is it then possible for the CGI to start using / send messages to the MC stacks already up and running? This has to be possible via some type of IAC but is the process started via the same as the mc engine running in the background... Wouldn't mind getting clear on these issues myself... ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: More CGI Stuff
It exists, it just hasn't made it on the site yet. Ruslan? Ruslan Does this mean there is a Mach-o version available now? I don't see it on your site. Cheers Dave
Re: More CGI Stuff
At 12:15 am +0300 31/8/02, Ruslan Zasukhin wrote: >on 8/31/02 0:04, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: > >> Correct. 2.4.2 is the last version with a CFM-based Carbon version. > >Okay, I ask because for > > MC Classic we have use XFCN > MC Carbon have use CODE resource > MC Mach-o use bundle Ruslan Does this mean there is a Mach-o version available now? I don't see it on your site. Cheers Dave ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: More CGI Stuff
Wouldn't it be even cooler if there was a metacard module for Apache which would allow for all these wonderful things in one easy step? In a word: yup. Brian
Re: More CGI Stuff
--On Saturday, August 31, 2002 20:51:31 -0400 [EMAIL PROTECTED] wrote: > Which is very cool stuff! > > I just want to point out one difference that I'm trying to obtain, > however: *multiple* long running processes with shared memory, and > everything done with Metacard! =). > > Since I want most of the work to happen in Metacard, its not as valuable > if I can only maintain one Metacard process- then the server can only > handle one connection at a time. And simply launching multiple copies of > say, MetacardCarbon, works- but its a major memory hog. Thus I'm trying > to work with scripts, rather than GUI processes. I can spawn 20 long > running scripts and it barely requires more memory than 1! > > Of course- PHP is still an option with multiple Metcard processes doing > the work, its just one more language to throw into the mix. Wouldn't it be even cooler if there was a metacard module for Apache which would allow for all these wonderful things in one easy step? > > Brian > > >> FWIW, I believe Pierre Sahores explained a way to use PHP to manage >> sockets and enable backend use of MC as a long-running process. I think >> it's related to this thread. (Wherever that explanation is in the >> archives, maybe Ken Ray would consider adding it to his already >> excellent Developer Resources section at http://www.sonsothunder.com !) >> > > Regards, Andu Novac ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: More CGI Stuff
Which is very cool stuff! I just want to point out one difference that I'm trying to obtain, however: *multiple* long running processes with shared memory, and everything done with Metacard! =). Since I want most of the work to happen in Metacard, its not as valuable if I can only maintain one Metacard process- then the server can only handle one connection at a time. And simply launching multiple copies of say, MetacardCarbon, works- but its a major memory hog. Thus I'm trying to work with scripts, rather than GUI processes. I can spawn 20 long running scripts and it barely requires more memory than 1! Of course- PHP is still an option with multiple Metcard processes doing the work, its just one more language to throw into the mix. Brian FWIW, I believe Pierre Sahores explained a way to use PHP to manage sockets and enable backend use of MC as a long-running process. I think it's related to this thread. (Wherever that explanation is in the archives, maybe Ken Ray would consider adding it to his already excellent Developer Resources section at http://www.sonsothunder.com !)
Re: More CGI Stuff
Phil Davis a écrit : > > - Original Message - > From: "David Bovill" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, August 30, 2002 11:33 AM > Subject: Re: More CGI Stuff > > > On Fri, 2002-08-30 at 16:13, [EMAIL PROTECTED] wrote: > > > > > > > Unfortunately, no- the server will spawn a new cgi process for each request. > > > I have found a couple options, however: > > > > > > 1). Run a simple server which takes request from cgi scripts (over sockets), > > > and supplies the persistent data. > > > > > > 2) Run a pool of servers, all listening on their own port, and then still > > > utilize 1). > > > > > > > With 2) is the idea to have the cgi script switch on each call to > > another process? > > > > > I did cook up something fun to play with. I stuck this in a script "httpd" > > > and call "./httpd 8080 10" from the terminal. What I get: 10 processes > > > listening on ports 8080-8089. > > > > > > > Re: my recent post are you using 2.4.3 with httpd? Having problems with > > my server under 2.4.3... > > > > In terms of IAC - which is what you are doing here right? Do you have > > any info regarding performance and the various techniques that are > > possible (in particular using an external, shell, and sockets)- what do > > you think: > > > > 1) Shell (slowest) > > > > 2) Sockets > > > > 3) Externals (any faster?) > > > > FWIW, I believe Pierre Sahores explained a way to use PHP to manage sockets and >enable backend use of MC as a long-running process. I think it's related to this >thread. (Wherever that explanation is in the archives, maybe Ken Ray would consider >adding it to his already excellent Developer Resources section at >http://www.sonsothunder.com !) > > Phil Hi Friends, Hi David, That's trough : under unixes, including Linux, xBSD, Solaris and probably MacOSX (just tested for yet in graphical mode), Metacard is able to run, in both console or graphical modes, as a backend deamon, just alike Apache or PostgreSQL. As Metacard is able to reply (with 100% of succes) to tcp/ip sockets messages, we have just to use a small cgi-script (.php than .mt prefered there) to bind Apache to the Metacard application server. As we can include in the small .php cgi script different "case of/socket port" statements, we can have more than a Metacard application server waiting for messages behind Apache, each one using a different port (under 1025 in root/console mode, over 1024 in user/graphical mode). The key points of the use of MC in this way is that it make us able to : 1.- build generic web and vpn applications servers able to store, betwin and along incoming queries, globals vars datas status in RAM ; 2.- think the application logical architecture before binding it to custom-props, files-based or SQL-based databases ; 3.- get more power and security in writting clean and reusable code than in using J2EE-based applications servers ; 4.- bind (directly, trough PHP or shell commands) to SQL servers each time we need to avoid to store to much datas in RAM (PostGreSQL greatly prefered there) ; 5.- run multi-threaded networked apps (up to 800 connections/secs on a Linux Suse 6.3 ATHLON 800 with 1Go of RAM/SWAP) in letting Apache/PHP open and manage multiple connections to the MC-based web application server ; 6.- ddevelopp once, install anywehre, even on the win2000 and up platform. Even in this kind of stuffs, Metacard can do us able to build the best professionnal apps. MC just let us think them :) I can, if needed, rewrite a resume of the detailled ways i use to set-up those kind of MC apps. -- Cheers, Pierre Sahores Inspection académique de la Seine-Saint-Denis Synthétiser et produire l'avantage compétitif Serveurs d'applications & de bases de données ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: More CGI Stuff
on 8/31/02 5:33, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: >>> FWIW, there is also a Darwin engine on X. >> >> What you mean ? MetaCard.app ? > > No- the Darwin version is separate. It is X11-based command line tool. You can > run scripts from Terminal, or if you install XDarwin you can run graphically > using X11. > > This build comes from the same source as the other half dozen or so UNIX > builds. > > If you got Valentina working with this, you would be very close to supporting > other UNIX platforms for VXCMD. We could probably do this with the mach-o ".a" > library for Valentina now. I believe you CAN do this with VXCMD macho Try this -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] - e-mail: [EMAIL PROTECTED] web: http://www.paradigmasoft.com To subscribe to the Valentina mail list send a letter to [EMAIL PROTECTED] - ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: More CGI Stuff
> FWIW, I believe Pierre Sahores explained a way to use PHP to manage sockets and enable backend use of MC as a long-running process. I think it's related to this thread. (Wherever that explanation is in the archives, maybe Ken Ray would consider adding it to his already excellent Developer Resources section at http://www.sonsothunder.com !) Thanks, Phil. I'll check the archives and see if I can come up with something. if anyone else knows where this is, please let me know and I will post it on my site. Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: More CGI Stuff
- Original Message - From: "David Bovill" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 30, 2002 11:33 AM Subject: Re: More CGI Stuff > On Fri, 2002-08-30 at 16:13, [EMAIL PROTECTED] wrote: > > > > > Unfortunately, no- the server will spawn a new cgi process for each request. > > I have found a couple options, however: > > > > 1). Run a simple server which takes request from cgi scripts (over sockets), > > and supplies the persistent data. > > > > 2) Run a pool of servers, all listening on their own port, and then still > > utilize 1). > > > > With 2) is the idea to have the cgi script switch on each call to > another process? > > > I did cook up something fun to play with. I stuck this in a script "httpd" > > and call "./httpd 8080 10" from the terminal. What I get: 10 processes > > listening on ports 8080-8089. > > > > Re: my recent post are you using 2.4.3 with httpd? Having problems with > my server under 2.4.3... > > In terms of IAC - which is what you are doing here right? Do you have > any info regarding performance and the various techniques that are > possible (in particular using an external, shell, and sockets)- what do > you think: > > 1) Shell (slowest) > > 2) Sockets > > 3) Externals (any faster?) > FWIW, I believe Pierre Sahores explained a way to use PHP to manage sockets and enable backend use of MC as a long-running process. I think it's related to this thread. (Wherever that explanation is in the archives, maybe Ken Ray would consider adding it to his already excellent Developer Resources section at http://www.sonsothunder.com !) Phil > > ___ > metacard mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/metacard > ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: More CGI Stuff
Okay, I ask because for MC Classic we have use XFCN MC Carbon have use CODE resource MC Mach-o use bundle So does this means that externals based on CODE resource have die ? Yes- for 2.4.3 and up on X. MC Classic can still use them in 2.4.3, we just have chosen XFCN for Supercard/Hypercard compatability. > FWIW, there is also a Darwin engine on X. What you mean ? MetaCard.app ? No- the Darwin version is separate. It is X11-based command line tool. You can run scripts from Terminal, or if you install XDarwin you can run graphically using X11. This build comes from the same source as the other half dozen or so UNIX builds. If you got Valentina working with this, you would be very close to supporting other UNIX platforms for VXCMD. We could probably do this with the mach-o ".a" library for Valentina now. Brian
Re: More CGI Stuff
on 8/31/02 0:04, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: > Correct. 2.4.2 is the last version with a CFM-based Carbon version. Okay, I ask because for MC Classic we have use XFCN MC Carbon have use CODE resource MC Mach-o use bundle So does this means that externals based on CODE resource have die ? > FWIW, there is also a Darwin engine on X. What you mean ? MetaCard.app ? > Brian > > Am I right that in 4.3 version we have > > -- MetaCard PPC (Classic app) > -- MetaCard.app (for X, mach-0) > > I.e we do not have CARBON version of MC to be used on 9 ? -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] - e-mail: [EMAIL PROTECTED] web: http://www.paradigmasoft.com To subscribe to the Valentina mail list send a letter to [EMAIL PROTECTED] - ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: More CGI Stuff
Correct. 2.4.2 is the last version with a CFM-based Carbon version. FWIW, there is also a Darwin engine on X. Brian Am I right that in 4.3 version we have -- MetaCard PPC (Classic app) -- MetaCard.app (for X, mach-0) I.e we do not have CARBON version of MC to be used on 9 ?
Re: More CGI Stuff
Hi Guys, Am I right that in 4.3 version we have -- MetaCard PPC (Classic app) -- MetaCard.app (for X, mach-0) I.e we do not have CARBON version of MC to be used on 9 ? -- Best regards, Ruslan Zasukhin [ I feel the need...the need for speed ] - e-mail: [EMAIL PROTECTED] web: http://www.paradigmasoft.com To subscribe to the Valentina mail list send a letter to [EMAIL PROTECTED] - ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: More CGI Stuff
With 2) is the idea to have the cgi script switch on each call to another process? Yup. I figure if I spawn many cgi scripts but they all have to talk to the same long-running process, then I've lost all of the benefits of multiple processes anyway. So yeah- I'm trying to get multiple processes on the cgi end talking to multiple processes over sockets. Of course, if I could accomplish everything I wanted to in a cgi script, I wouldn't bother with the long-running processes. Re: my recent post are you using 2.4.3 with httpd? Having problems with my server under 2.4.3... I use my own server stack, although it works similarly to httpd. In limited tests, it works fine here under 2.4.3 / MacOS 10.1. In terms of IAC - which is what you are doing here right? Do you have any info regarding performance and the various techniques that are possible (in particular using an external, shell, and sockets)- what do you think: 1) Shell (slowest) 2) Sockets 3) Externals (any faster?) I'm really just experimenting, so I don't have much evidence. However, I would say that sockets are probably more efficient that shell calls and using "open process" is probably at least as fast as sockets. I don't think externals would be much help unless under the hood unless they can access something faster than what Metacard already has- and I don't know what that would be! FWIW, Brian
Re: More CGI Stuff
On Fri, 2002-08-30 at 16:13, [EMAIL PROTECTED] wrote: > > > Unfortunately, no- the server will spawn a new cgi process for each request. > I have found a couple options, however: > > 1). Run a simple server which takes request from cgi scripts (over sockets), > and supplies the persistent data. > > 2) Run a pool of servers, all listening on their own port, and then still > utilize 1). > With 2) is the idea to have the cgi script switch on each call to another process? > I did cook up something fun to play with. I stuck this in a script "httpd" > and call "./httpd 8080 10" from the terminal. What I get: 10 processes > listening on ports 8080-8089. > Re: my recent post are you using 2.4.3 with httpd? Having problems with my server under 2.4.3... In terms of IAC - which is what you are doing here right? Do you have any info regarding performance and the various techniques that are possible (in particular using an external, shell, and sockets)- what do you think: 1) Shell (slowest) 2) Sockets 3) Externals (any faster?) ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: More CGI Stuff
Can this be done by having MC running in the background *prior* to the cgi being called by the server - not sure how the os associated the script with the engine or whether it creates another process would like to though:) Unfortunately, no- the server will spawn a new cgi process for each request. I have found a couple options, however: 1). Run a simple server which takes request from cgi scripts (over sockets), and supplies the persistent data. 2) Run a pool of servers, all listening on their own port, and then still utilize 1). I did cook up something fun to play with. I stuck this in a script "httpd" and call "./httpd 8080 10" from the terminal. What I get: 10 processes listening on ports 8080-8089. This is somewhat like apache's behavior: a bunch of child processes handle requests. Problem is, Apache uses fork() and select(), so it manages to get all of the processes listening on the *same* port. I can't see how that is possible with Metacard. #!mc global thisPort, myID, isLastChild on startup put $1 into thisPort put $2 into numChildren put $3 into myID put $4 into isLastChild if (myID is empty) then put 0 into myID accept connections on port thisPort with message "newConnect" repeat with pID=1 to numChildren-1 open process ($0&&($1+pID)&&"0"&&(pID)&&(pID = (numChildren - 1))) end repeat end startup on newConnect s read from socket s until empty put "HTTP/1.0 200 OK WebCF"&crLF into r put "Content-Type: text/plain"&crLF after r put "Content-Length: "&length(myID)&crLF&crLF after r put myID after r write r to socket s end newConnect
Re: More CGI Stuff
On Wed, 2002-08-28 at 23:58, [EMAIL PROTECTED] wrote: > Of course now I just need a way to maintain some persistent memory (i.e. > database cache). Any ideas? I can write globals to disk if needed, but I > can't afford to re-create the database cache on every run of the script. > Sounds like maybe I need to wait for Valentina Server. > Can this be done by having MC running in the background *prior* to the cgi being called by the server - not sure how the os associated the script with the engine or whether it creates another process would like to though:) Otherwise I guess it could be done using some sort of IAC messaging? ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: More CGI Stuff
Eh! You're right- it does work. It seems I had written off the MacOS engine for scripts (I've been using the Darwin engine) for other reasons (namely "open process" behavior). Anyway, externals can be used through scripts just fine by way of "start using" with the mach-o engine and a mach-o external. Of course now I just need a way to maintain some persistent memory (i.e. database cache). Any ideas? I can write globals to disk if needed, but I can't afford to re-create the database cache on every run of the script. Sounds like maybe I need to wait for Valentina Server. Brian This should just work on Win32 and MacOS systems. You can either send messages to the stack with the external, or use "start using" to insert it into the message hierarchy. If it really doesn't work, please file a bug report.
Re: More CGI Stuff
On Wed, 28 Aug 2002 [EMAIL PROTECTED] wrote: > So my question... is there *any* way to access externals (including > the new Mach-o ones with 2.4.3) from a CGI script? This should just work on Win32 and MacOS systems. You can either send messages to the stack with the external, or use "start using" to insert it into the message hierarchy. If it really doesn't work, please file a bug report. Regards, Scott Scott Raney [EMAIL PROTECTED] http://www.metacard.com MetaCard: You know, there's an easier way to do that... ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
More CGI Stuff
Hi guys, With all of this CGI talk lately, I cooked something up. I've been working with a server program based on the ol' mc httpd stack, since I make heavy use of Valentina. However, I've always wanted to break it down into separate cgi scripts. Among other things, that gives me multiple processes more easily. So my question... is there *any* way to access externals (including the new Mach-o ones with 2.4.3) from a CGI script? The best I can come up with is running a separate stack which houses the external, and communicating via sockets. Any ideas? In case anyone finds this script useful, this is what I'm using to talk to my mc httpd-inspired stack: #!mc on startup open socket to "127.0.0.1:8080" put $REQUEST_METHOD&&$REQUEST_URI&&"CGI"&crLF into theRequest if ($HTTP_COOKIE is not empty) then put "Cookie: "&$HTTP_COOKIE&crLF after theRequest end if if ($REMOTE_USER is not empty) then put "Remote-User:"&&$REMOTE_USER&crLF after theRequest end if if ($REQUEST_METHOD = "PUT") then read from stdin until empty put crLF&it after theRequest end if write theRequest&crLF&crLF to socket "127.0.0.1:8080" read from socket "127.0.0.1:8080" until (crLF&crLF) put it into theHeaders put lineOffset(theHeaders, "Content-Length:") into theLine if (theLine > 0) then set the itemDelimiter to ":" put item 2 of line theLine of theHeaders into theLength read from socket "127.0.0.1:8080" for theLength put it into theBody else read from socket "127.0.0.1:8080" until empty put it into theBody end if ## delete the status line delete line 1 of theHeaders put (theHeaders&crLF&crLF&theBody) end startup Best Regards, Brian
