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

[Morbus I. <mo...@di...>]

> 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.
> of the extra installation step?  If so, why not just make a big

"don't use modules" should have been more adequately rephrased as "don't use
modules that need to be downloaded and installed". My reasoning for this is
two fold:

 a) Stupid users don't understand telnet's, so they can't run
     the typical Make process. Nor do a lot of webhosts provide
     shell access to even get them that far.

 b) Although a webhost shouldn't have any problem installing
    modules, it does make the installation process slower. No
    one wants to wait around whilst some overtaxed and uncaring
    webhost piddles around before they get to your request.
    (I'm ignoring the inevitable cries of "choose a different webhost").

 c) And including the modules with the source probably wouldn't
    make a good solution anyways - even if you did make some
    sort of CGI based install script to run the commands needed,
    they wouldn't go into the same place.

Perhaps the whole request should be rephrased as "create a slashcode that
the user needs only FTP access to install and administer". In association
with that, "create a slashcode that an ISP isn't going to be afraid to
install." Working at an ISP as the sysadmin, and asking the boss to install
this, I can see two main concerns from him:

 a) recompile apache? uh huh. ok, buddy.
 b) run a daemon? that's not good. uh huh. ok, buddy.

> 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

Ah... Is there any documentation or pointers on this? I do have an Apache
compiled with DSO, but am curious about the "often won't work" statement.

> modules, no caching of templates (though this could be worked around to
> some degree), no caching of data.  It would be slow.

Slow for the current Slashdot population or slow in general? How slow is
slow? We know how many hits Slashdot gets, and the code certainly reflects
that needs. Is that the goal statement of Slashcode? To provide a CMS that
can work in million hit per day installations? That should be up front
somewhere.

I get only thousands of hits per day. Is Slashcode too good for me? Do I
need all this caching and super power if it's never going to be used?
Perhaps my request is stupid from the start because the daemon, speed
lovin', caching, and all that junk is overkill for my installation.

And what about the people who just want to run Slashcode on their intranet?
Or for people who want to run a "NeedleMakers in the 402", which is going to
have a incredibly small audience. Is Slashcode too good for them as well?
They certainly don't need caching.

I'm not trying to be harsh, or to diss Slashcode, or anything of that
effect. Slashcode, while great, just isn't accessible to a large audience.
Maybe that's a goal statement somewhere, but my head runs "100% everyone
everywhere". Slashcode is currently "geeks who have their own servers or
isp's who love their geeks".