On Thu, 27 May 1999, Michael Fair <[EMAIL PROTECTED]> wrote:
>
> As far as an archive of the list goes, this list is maintained
> by Majordomo which only has an email interface as far as
> I know. It's not complex for those who know, but I find
> it difficult to use.
> As a shameless plug for a different listserver, I have
> always used mailman as my listserver which automatically
> comes with a web interface for all subscription,
> administration, and archiving purposes, is actively
> developed and are adding search features soon.
> It does everything that Majordomo does as far as I can
> tell. The website is http://www.lists.org/
Actually, that's a link to a Majordomo site ;-)
Majordomo does have a lot of limitations, but it does the job and is
proven technology. Given that it's already set up, the odds of us
dumping that to install a version 1.0 package like Mailman are about
zero.
> > >Without being to "include" scripts, or some other kind
> > >of library feature, I am stuck with copy and paste, or
> > >limiting myself to what I can type, making it near
> > >impossible to leverage other people's code.
> >
> > Just tuck 'em into backscripts. There's no limit to the number of
> > backscripts which can be in use at any given time, and the syntax for
> > using them is a snap:
>
> Will this work with using mc as a web cgi engine too?
Yes, but since the scripts need to be in stacks, the 10-limit Starter
Kit limit would apply.
> We were discussing what cgi architecture to engineer
> our web sites with, the only drawbacks to Metacard for
> me were those two features, which I deemed unavailable.
There was a discussion of this issue on the xTalk list awhile back,
but the thread died out before any good solution to the problem of
including scripts from files into other scripts was developed. I
think the big problem was that few people understood (or cared about)
the issues because they all work in a stack-based environment where
"start using" and "insert script" are better ways to do this kind of
thing than including scripts directly from files.
> 1) The regex limitation, which isn't big, but kind
> of annoying.
I understand the problem (I think it's called "greedy matching"), but
since all other regex patterns work the same way, I'm puzzled as to
why you think it's a problem in MetaCard but not in
Perl/Python/Tcl/etc? How do you get short matches in any of these
other languages?
As for MetaCard's regex, it's based on the original Spencer code, just
like Perl, Python, and Tcl's regex packages are. The Perl and Tcl
regex packages have been substantially rewritten, however. MetaCard's
hasn't. We've looked into trying to incorporate Perl 5's rewritten
regex package, but it would apparently be very difficult to extract
from the Perl environment. Maybe this is something the OpenCard
developers would be able manage ;-)
> 2) The library limitation, which is a more serious problem
> if you are going to be investing any significant amount
> of time/code into a web site.
>
> I want to use Metacard so I can program in MetaTalk
> which will make the port to OpenScript easier. However,
> without that librarying capability from the scripting engine
> I couldn't consider it a smart idea until I was sure I would
> be able to leverage that really cool web widget system
> some kid in Arkansas wrote.
The librarying issue only comes up when using MetaCard as a CGI, and
is not a reason for not using MetaCard for developing a development
environment for OpenCard. And IMHO, CGI is soon to be another WWW
dead-end (just like plug-ins were) because the superior performance
and much easier development and management provided by integrated
servers will eventually render CGI-based solutions obsolete.
Regards,
Scott
> - -- Michael --
PS: as for that development environment project, I noticed that
discussion on the licensing issue and election of a "license master"
has about died out. It would be good to see that get finished up so
that the scripters out there could get started on the UI development
project...
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
