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

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

At 11:01 -0400 2001.04.20, Morbus Iff wrote:
> 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.

I don't understand what you mean by this.  You create a directory, and put
the modules in it.  You probably add a configuration option somewhere for
where to look for the modules.

Let's assume you can do this.  OK, so you want to not have to install
XML::Parser.  XML input was one of your requirements, so you need to parse
it somehow.  You need to have a binary of XML::Parser.  Heck, LOTS of
binaries, one for each platform this is going to.  Or you need to write an
all-perl XML parser.  You can't do it.  You need XML::Parser.  You need to
have expat.  You need to build it especially for your OS.  Or you can try
to find some other XML parser.

And then there is the templating system.  You could try to write your own,
but that would take months or years to come up with one that works this
well.  You could do what Slash 1.x did, and put perl in the database, but
that is quite insecure (though you can use the Safe module to try to work
around it).  In fact, if you want to use Slash via FTP only, Slash 1.0
might be a better starting point, since it has far fewer external
dependencies.

Slash was written to be good software to run Slashdot and sites that want
to be simimlar to Slashdot (not necessarily in traffic, but in function).
It was not written to be something anyone can pick up and use without any
knowledge.  Again, if this is really what you want, you would probably be
better off starting from scratch.


>> 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.

Beats me.  I never use DSO.  :)


>> 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?

Yes.  Slash is bigger now than it used to be, and will be significantly
slower than it was before, without caching, even with no significant
traffic.  There are ways to work around it, especially by caching templates
to disk instead of memory.


>And what about the people who just want to run Slashcode on their intranet?

Then they should be able to install it all without a problem.


>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.

I dunno, we have a large number of people who use it.


>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".

Nah.  That's like saying Apache is only for geeks.  Yes, the average user
cannot set it up.  I don't see why this is a problem, anymore than I can
see why the average user not being able to set up Apache is a problem.

I realize that Slash is cool, and it would be nice if anyone could "just
use it."  The technological reality is that the reasons why Slash is so
cool are some of the same reasons why not everyone can "just use it."
Things like templates and database access and XML etc.

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