Re: [Slashcode-general] Can I run slashcode via cgi-bin of an ISP?

[Chris N. <pu...@po...>]

At 09:20 -0400 2001.04.20, Morbus Iff wrote:
>Slashcode-Lite type of port, called Slashcod (an in-joke from LILO). My
>desires were:
>
>   a) no module installation.
>   b) optional database support (which he tells me is possible, but
>      one would need to write a DBD::CSV implementation, which
>      probably violates a)
>   c) xml support (which after talking with him is nothing more
>      than a DBD type of port, so shouldn't be a big deal).
>   d) no apache recompile.
>
>The big, big, big one is a). That's no template-toolkit, none of the dozens
>of other required modules. A lot of code would have to rewritten, I
>believe, just to support the stupid user. Some people don't believe that
>stupid users should have access to this power. I disagree.

It is not about them having access to "power."  No one ever said anything
like that.  It is about us making the best code we can, and that means
using preexisting code.  It is about us making the best use of our time,
which means not making one distribution for everything.

I don't think it makes any sense to say "don't use modules."  That makes as
much sense as saying "don't install Slash."  They equate to the same thing.
I am not sure why you would not want to install the modules.  Is it because
of the extra installation step?  If so, why not just make a big
distribution that already includes the modules?  We won't, because we have
more important things to do.  But there's nothing stopping someone else
from doing that.

It would be nothing at all like Slash if you take away database support,
template-toolkit, etc.  You might as well just start a new project from
scratch.  That would be like wanting Mac OS "without that silly GUI."  But
modules are not a reasonable impediment to use of Slash.  They just aren't.
All it takes is someone to prepackage all the necessary modules into one
easy-to-install distribution, which is not difficult.  But it is
time-consuming.


>I never did understand why d) was needed.

If you can get mod_perl to build with DSO, it isn't.  If you can get an
Apache/mod_perl binary that already has the proper configurations built in,
it isn't.  But most of the time Apache is not built with DSO support, and
even if it is, it often won't work properly with mod_perl.  And most
prepackaged Apache/mod_perl binaries do not have the proper configurations
built-in.

Apparently, it does work now with the correct Debian packages, which is
great.  But we cannot control the distributions.  And we cannot control
sysadmins who don't -- or won't -- supply the configuration options we need.

If you really really want to avoid mod_perl (which is what you are asking
for, if you don't want a recompile of Apache for Apache builds that won't
work already), then that means you want to run Slash just as CGIs.  This is
possible.  It is very much not advisable.  You would get no caching of
modules, no caching of templates (though this could be worked around to
some degree), no caching of data.  It would be slow.

But I do not see any reason why there needs to be a separate project just
for this.  What needs to happen is someone (or someones) needs to sit down
and find all the places in Slash where the code needs to change to support
the need.  Then we would need to look at all of those places and see if it
is feasible to incorporate those necessary changes into Slash.

As to XML support: what you wanted was importing of stories via XML.  That
is not a DBD type of port (I am not sure what that means).  What it would
take is just creating a plugin or script to extend Slash.

So, to sum up:

    a) You don't need to not install modules.  You really don't.
    b) You do need a database if you want any kind of reasonable performance.
       If you want to port it to comma-separated-values or something similar,
       more power to you, but it won't be fast, and it will take some
       significant work to put together; this is true whether you work with
       Slash, or start a separate project, so I don't see much point in
starting
       a separate project over this point.
    c) Almost any additional features can be added to Slash via plugins or
       standalone scripts, etc.  That's not a problem for Slash, it is just
       work to write the code you need.
    d) If you don't want to recompile Apache, you can try to get DSO support,
       or try the proper Debian packages.

-- 
Chris Nandor                      pu...@po...    http://pudge.net/
Open Source Development Network    pu...@os...     http://osdn.com/