[Metacard] Digest metacard.v004.n531
metacard-errors at www.runrev.com
metacard-errors at www.runrev.com
Sun Nov 25 17:37:01 EST 2001
-------------- BEGIN metacard.v004.n531 --------------
001 - Richard MacLemale <rmacle - CGI under OS X via Darwin Success...
002 - Sivakatirswami <katir at hin - Open Stack With CGI on UNIX Server?
003 - Pierre Sahores <psahores@ - Re: CGI under OS X via Darwin Success...
004 - Pierre Sahores <psahores@ - Re: Open Stack With CGI on UNIX Server?
005 - Dave Cragg <dcragg at lacsce - Re: Win XP: a new dawn
This is the MetaCard mailing list.
Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send any bug reports to <bugs at metacard.com>, not this list.
--------------- MESSAGE metacard.v004.n531.1 ---------------
From: Richard MacLemale <rmaclemale at earthlink.net>
Subject: CGI under OS X via Darwin Success...
Date: Sat, 24 Nov 2001 16:24:56 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <200111241742.MAA04763 at www.runrev.com>
Thanks to all who helped both on list and off. The MetaCard mailing list
rocks almost as much as MetaCard itself...
I've got the Darwin engine handling MetaCard scripts via CGI working very
well now. I still have a lot to learn, but "the basics" are a done deal.
So I thought I'd share what I learned. I'm eventually going to put together
a web page on using MetaCard's Darwin engine to do CGI on OS X, but in the
meantime, for anyone else attempting this, here's some roadblocks that I had
to jump...
1. Installing the darwin engine is way simple. I was trying to get all
fancy, but in reality all you have to do is download the darwin engine, the
tools and home stacks, and double-click them. Stuffit will uncompress and
unpack them. Then just put them in the following folder:
/Library/WebServer/CGI-Executables
Also get a copy of the echo.mt file and put THAT in the same folder.
2. Obviously make sure Apache is running by typing in:
http://(your IP address)/
And you should get a default Apache page.
3. I had to edit the httpd.conf file. For some reason, once I got echo.mt
working, it only worked every OTHER time I clicked on it. I uncommented the
following line in httpd.conf:
AddHandler cgi-script .cgi
After I did that, echo.mt worked every time. Why? I dunno. Speaking of
echo.mt, mine was returning everything in one line to my browser, instead of
in separate lines like the one on the metacard site does. I changed
put "Content-Type: text/text" & cr
to
put "Content-Type: text/html" & cr
and now it works perfectly.
4. BB Edit Lite for OS X is a MUST HAVE tool. And it's free. Not only
will it allow you to find hidden files, it will also allow you to edit files
like httpd.conf and save them with UNIX line breaks (you have to choose Save
As.) If you save a UNIX file without UNIX line breaks, it will... break.
5. Permissions are critical. Obviously you have to give mc the ability to
execute.
I couldn't get a script to create a new text file and write to it, or to
open an existing text file and read or write to it. Then I remembered (duh)
permissions. As long as the file exists, and the permissions are set
correctly, a metacard script can open a text file and write to it or read
from it. So cool.
6. If you don't know some basic UNIX, you can't do this cool stuff. Good
thing I'm learning UNIX...
This unlocks the candy store for me. One thought goes through my mind,
though... Suppose an individual were to download the darwin engine, and the
home and tools stacks... And suppose they install them and write some neato
mt scripts for their OS X based web site. Scott says that the script limit
does not apply to the Darwin engine when running in non-GUI mode. Doesn't
this mean that anyone who wanted to could do CGI stuff with MetaCard for
free? If this is intentional, then it should be, well, advertised. Maybe
as a way of getting some UNIX or Mac OS X people in the door. MetaTalk is a
kabillion times easier to learn than Perl...
Just thinkin' out loud.
:)
Richard MacLemale
Instructional Technology Specialist
James W. Mitchell High School
--------------- MESSAGE metacard.v004.n531.2 ---------------
From: Sivakatirswami <katir at hindu.org>
Subject: Open Stack With CGI on UNIX Server?
Date: Sat, 24 Nov 2001 11:42:15 -1000
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
I am considering the option of storing HTML template data and code chunks in
a MC stack on a server and running MC .cgi scripts to tell Apache to get
that data, build pages and serve the HTML... Since I don't know PHP, PERL,
ASP and really have no intention/time to learn them... xTalk is pretty much
my only option (and also, the "easier way to do that") We asked this
before, but didn't get much feedback... maybe no one is doing it?
Options are:
a) store the code in fields of the stack and call the fields
(easier to manage)
b) store the code in customProperties of a stack and get the properties
c) store code in small text files... (gets back to reading everything from
disk each time)
Using a script like this:
on startup
open stack "../htmlDataBase/templateData.mc
## extract the data, build the page(s), email(s)
## serve the page (s); send the email(s)
end startUp
Questions arise:
1) Does the "open stack" syntax "mean" anything in the no console mode of
MC? i.e. is the stack actually opened and loaded into the RAM of the host
server by the mc.cgi/apache, thereby making the custom properties
"instantly" available as opposed to reading text files from disk? i.e. there
would be a single file read, and the rest done in memory?
or if the "open Stack" syntax doesn't really load the stack into the HOST
ram...then I guess it means each call for field or custom property data is
in fact a disk read...
Which is it?
2) Is there an I/O issue for multiple, near simultaneous hits to the CGI,
where the data for two simultaneous hits on the same CGI asking for data
from a single stack could be a problem?
I am no so much worried about time to serve the pages [as far as I can see
.asp and java scripts that serve HTML pages from databases are already
painfully slow and MC I expect will easily outperform them...]
The underlying, unresolved, bigger question/worry is, obviously... how to
optimize so that multiple simultaneous hits during peak access period don't
cause Apache to error out? And, would it be better to have all the code be
simple, separate text files--painful to manage, but perhaps easier for the
I/O routines of the server? anyone have experience in this area?
Hinduism Today
Sivakatirswami
Editor's Assistant/Production Manager
katir at hindu.org
www.HinduismToday.com, www.HimalayanAcademy.com,
www.Gurudeva.org, www.hindu.org
Read The Master Course Lesson of the Day at
http://www.gurudeva.org/lesson.shtml
--------------- MESSAGE metacard.v004.n531.3 ---------------
From: Pierre Sahores <psahores at easynet.fr>
Subject: Re: CGI under OS X via Darwin Success...
Date: Sun, 25 Nov 2001 00:20:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
References: <200111242125.QAA07494 at www.runrev.com>
Richard MacLemale a écrit :
>
> Thanks to all who helped both on list and off. The MetaCard mailing list
> rocks almost as much as MetaCard itself...
>
> I've got the Darwin engine handling MetaCard scripts via CGI working very
> well now. I still have a lot to learn, but "the basics" are a done deal.
> So I thought I'd share what I learned. I'm eventually going to put together
> a web page on using MetaCard's Darwin engine to do CGI on OS X, but in the
> meantime, for anyone else attempting this, here's some roadblocks that I had
> to jump...
>
> 1. Installing the darwin engine is way simple. I was trying to get all
> fancy, but in reality all you have to do is download the darwin engine, the
> tools and home stacks, and double-click them. Stuffit will uncompress and
> unpack them. Then just put them in the following folder:
> /Library/WebServer/CGI-Executables
>
> Also get a copy of the echo.mt file and put THAT in the same folder.
>
> 2. Obviously make sure Apache is running by typing in:
> http://(your IP address)/
>
> And you should get a default Apache page.
>
> 3. I had to edit the httpd.conf file. For some reason, once I got echo.mt
> working, it only worked every OTHER time I clicked on it. I uncommented the
> following line in httpd.conf:
>
> AddHandler cgi-script .cgi
>
> After I did that, echo.mt worked every time. Why? I dunno. Speaking of
> echo.mt, mine was returning everything in one line to my browser, instead of
> in separate lines like the one on the metacard site does. I changed
> put "Content-Type: text/text" & cr
> to
> put "Content-Type: text/html" & cr
> and now it works perfectly.
>
> 4. BB Edit Lite for OS X is a MUST HAVE tool. And it's free. Not only
> will it allow you to find hidden files, it will also allow you to edit files
> like httpd.conf and save them with UNIX line breaks (you have to choose Save
> As.) If you save a UNIX file without UNIX line breaks, it will... break.
>
> 5. Permissions are critical. Obviously you have to give mc the ability to
> execute.
>
> I couldn't get a script to create a new text file and write to it, or to
> open an existing text file and read or write to it. Then I remembered (duh)
> permissions. As long as the file exists, and the permissions are set
> correctly, a metacard script can open a text file and write to it or read
> from it. So cool.
>
> 6. If you don't know some basic UNIX, you can't do this cool stuff. Good
> thing I'm learning UNIX...
>
> This unlocks the candy store for me. One thought goes through my mind,
> though... Suppose an individual were to download the darwin engine, and the
> home and tools stacks... And suppose they install them and write some neato
> mt scripts for their OS X based web site. Scott says that the script limit
> does not apply to the Darwin engine when running in non-GUI mode. Doesn't
> this mean that anyone who wanted to could do CGI stuff with MetaCard for
> free? If this is intentional, then it should be, well, advertised. Maybe
> as a way of getting some UNIX or Mac OS X people in the door. MetaTalk is a
> kabillion times easier to learn than Perl...
>
> Just thinkin' out loud.
>
> :)
> Richard MacLemale
> Instructional Technology Specialist
> James W. Mitchell High School
>
> Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
> Info: http://www.xworlds.com/metacard/mailinglist.htm
> Please send bug reports to <bugs at metacard.com>, not this list.
Hi Richard,
Thank's for yours usefull explainations. I will have to do with this in
the next months, too :-)
Best Regards, Pierre Sahores
WEB & VPN applications & databases servers
Inspection académique de Seine-Saint-Denis
Qualifier & produire l'avantage compétitif
--------------- MESSAGE metacard.v004.n531.4 ---------------
From: Pierre Sahores <psahores at easynet.fr>
Subject: Re: Open Stack With CGI on UNIX Server?
Date: Sun, 25 Nov 2001 01:00:31 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
References: <200111242143.QAA07595 at www.runrev.com>
Sivakatirswami a écrit :
>
> I am considering the option of storing HTML template data and code chunks in
> a MC stack on a server and running MC .cgi scripts to tell Apache to get
> that data, build pages and serve the HTML... Since I don't know PHP, PERL,
> ASP and really have no intention/time to learn them... xTalk is pretty much
> my only option (and also, the "easier way to do that") We asked this
> before, but didn't get much feedback... maybe no one is doing it?
>
> Options are:
>
> a) store the code in fields of the stack and call the fields
> (easier to manage)
> b) store the code in customProperties of a stack and get the properties
>
> c) store code in small text files... (gets back to reading everything from
> disk each time)
>
> Using a script like this:
>
> on startup
> open stack "../htmlDataBase/templateData.mc
> ## extract the data, build the page(s), email(s)
> ## serve the page (s); send the email(s)
> end startUp
>
> Questions arise:
>
> 1) Does the "open stack" syntax "mean" anything in the no console mode of
> MC? i.e. is the stack actually opened and loaded into the RAM of the host
> server by the mc.cgi/apache, thereby making the custom properties
> "instantly" available as opposed to reading text files from disk? i.e. there
> would be a single file read, and the rest done in memory?
>
> or if the "open Stack" syntax doesn't really load the stack into the HOST
> ram...then I guess it means each call for field or custom property data is
> in fact a disk read...
>
> Which is it?
>
> 2) Is there an I/O issue for multiple, near simultaneous hits to the CGI,
> where the data for two simultaneous hits on the same CGI asking for data
> from a single stack could be a problem?
>
> I am no so much worried about time to serve the pages [as far as I can see
> .asp and java scripts that serve HTML pages from databases are already
> painfully slow and MC I expect will easily outperform them...]
>
> The underlying, unresolved, bigger question/worry is, obviously... how to
> optimize so that multiple simultaneous hits during peak access period don't
> cause Apache to error out? And, would it be better to have all the code be
> simple, separate text files--painful to manage, but perhaps easier for the
> I/O routines of the server? anyone have experience in this area?
>
> Hinduism Today
>
> Sivakatirswami
> Editor's Assistant/Production Manager
> katir at hindu.org
> www.HinduismToday.com, www.HimalayanAcademy.com,
> www.Gurudeva.org, www.hindu.org
>
> Read The Master Course Lesson of the Day at
> http://www.gurudeva.org/lesson.shtml
>
> Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
> Info: http://www.xworlds.com/metacard/mailinglist.htm
> Please send bug reports to <bugs at metacard.com>, not this list.
Hi Sivakatirswami,
All you need to get the rights answers is to learn how to get mc stacks
running as long processes in console mode. As it runs fine under Linux,
it must run under Solaris8 too without problems.
If you choose to use an MC long running process stack to serve datas to
the web trough Apache, you will never got errors as long as you will use
a non metatalk stuff (script or long process) to link Apache and your
web mc stack together, trough a TCP/IP socket. You will there need to
use a small 20 lines script, written in Perl, Python or as me, in PHP.
If interested, just see about the subject what i wrote times ago in the
mc archives at
<metacard at lists.best.com> or <metacard at lists.runrev.com>.
Too be sure, you can handle stacks as long processes in console mode,
just use this (right running under Linux, not tested under Solaris8 x86
for yet) :
> Pierre Sahores wrote:
> >
> > Just alike you start other console apps from the bash prompt. To test
> > this, just launch, from the shell, a new "test.mc" stack that only
> > contains :
> >
> > on openstack
> > put "Hello World"
> > end openstack
> >
> > in typing "/home/pierre/startmc &" at the prompt where startmc, set
> > with an executable permission, contains :
> >
> > #!/home/pierre/mc
> > on startup
> > open stack "/home/pierre/test.mc"
> > end startup
> >
> > If all is right done, you will see the "Hello World" ansered at
> > prompt... and, in opening "KSysGuard", you will see the "startmc" line
> > entry, as a still running process...
> >
> > > doesn't it need X?
> >
> > No. You need just an rc.d (level 3) bash starter script pointing to the
> > stack you want to launch in the background (see the list archives). The
> > only metatalk feature unavailable in console mode is the "idle"
> > function. Is'n it great (Thanks again and again, Scott...) ?
> >
> This is really nice, thanks for the tip.
> >
> > Have fun, Pierre Sahores
> >
> > WEB & VPN applications & databases servers
> > Inspection académique de Seine-Saint-Denis
> > Qualifier & produire l'avantage compétitif
> Andu
--
Best Regards, Pierre Sahores
WEB & VPN applications & databases servers
Inspection académique de Seine-Saint-Denis
Qualifier & produire l'avantage compétitif
--------------- MESSAGE metacard.v004.n531.5 ---------------
From: Dave Cragg <dcragg at lacscentre.co.uk>
Subject: Re: Win XP: a new dawn
Date: Sun, 25 Nov 2001 21:50:44 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
References: <200111231015.FAA18491 at www.runrev.com>
<200111231628.LAA21425 at www.runrev.com>
<200111232228.RAA26599 at www.runrev.com>
In-Reply-To: <200111232228.RAA26599 at www.runrev.com>
A follow-up.
There is some information on the proper way to do things on Microsoft's site:
<http://www.microsoft.com/winlogo/downloads/software.asp>
Then download (Word doc of course) from the following link:
"Designed for Microsoft Windows XP" Application Specification 2.2
To follow these requirements, it looks like we need a few additions
to the specialFolderPath function on Windows. I've listed these below
along with the value of the SHGetFolderPath API that the above doc
says should be used to get these.
Program Files directory (CSIDL_PROGRAM_FILES)
Common Application Data (machine specific) (CSIDL_COMMON_APPDATA)
User Application Data (user specific, roaming) (CSIDL_APPDATA)
User Local Application Data (user specific, non-roaming) (CSIDL_LOCAL_APPDATA)
It may be possible to get these locations from the registry (anyone
know?), but the above doc warns against it.
Configuration data can be stored in the registry, of course, but only
if it's small. However, for the new "limited user" accounts, the only
place to put common application data is in the common application
data folder. (And even that requires some permission tweaking, but
apparently we're allowed to do that.)
Any chance of this, Scott? Then we can add the XP logo to our apps
(after paying for independent verification and complying with a few
hundred other requirements), and succumb completely. Ahh, the
ecstasy! :)
Cheers
Dave Cragg
--------------- END metacard.v004.n531 ---------------
More information about the metacard
mailing list