From: Adam K. <as...@en...> - 2001-04-20 22:38:48
|
Can someone point me to where I can read about extracols? I posted this question about a week ago and got some helpful replies but not enough to get me going. Basically, it seems that this was used for book reviews and while it hasn't changed from Slash1 to Slash2, it should still work as a vestige of Slash1. But how do I activate these extra columns? Adam Khan as...@en... |
From: Chris N. <pu...@po...> - 2001-04-23 14:20:41
|
At 16:43 -0500 2001.04.20, Joel Kleppinger wrote: >Consider this the long way of saying, "You guys make a great product, >however, you have little foundation to stand on when someone complains >about it being difficult to install." While it might be nice to have a CD If you don't already have mod_php compiled in to Apache properly, and don't already have the database server installed, then the PHP projects will be "difficult" too. >Even though I don't know much perl, I believe that what is holding slash >back from being easier to install is the fact that perl just doesn't come >with all of those modules installed. Nope. Many of the things required here would be additional modules or code for PHP, too! The same reasons why you -- and pretty much everyone -- admits that Slash is so much more powerful than PHP* are the same reasons why we have external modules required. We could go the other way, I suppose: reimplement all the code ourselves. But that is extraordinarily unproductive use of our time. And we could bundle it all together, but that can be done by ANYONE. I have heard many people say they don't want to install extra modules, and we always say "someone just needs to make a distribution that already has everything needed in it," and people expect us to do that, but no one else seems to think it is worth doing themselves. I don't really mind that no one is doing it; but I see no room for complaint that it doesn't exist. This is an open source project. The code is all there. If there is enough interest in an all-in-one distribution, then I don't see why no one is doing it. The only thing I can figure is that there really isn't that much interest (or that someone is doing it, but I just don't know about it :-). -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
From: Joel K. <jkl...@ea...> - 2001-04-23 14:52:48
|
At 10:20 AM 4/23/2001 -0400, you wrote: >At 16:43 -0500 2001.04.20, Joel Kleppinger wrote: > >Consider this the long way of saying, "You guys make a great product, > >however, you have little foundation to stand on when someone complains > >about it being difficult to install." While it might be nice to have a CD > >If you don't already have mod_php compiled in to Apache properly, and don't >already have the database server installed, then the PHP projects will be >"difficult" too. That's not the point. No self-respecting shared (or even dedicated) web host isn't going to offer both mod_perl, mod_php, mysql and whatever else. The difference is, for slash, you have to have recompile mod_perl and possibly/probably apache as well. I know nothing I say or do will change that because I understand the reasons for it. But don't shrug off recompilations by saying "well everyone has to do it." Stop thinking about this discussion in dedicated server terms, at least for my sake. > >Even though I don't know much perl, I believe that what is holding slash > >back from being easier to install is the fact that perl just doesn't come > >with all of those modules installed. > >Nope. Many of the things required here would be additional modules or code >for PHP, too! The same reasons why you -- and pretty much everyone -- >admits that Slash is so much more powerful than PHP* are the same reasons >why we have external modules required. > I don't remember saying slash was more powerful than PHP. What I said was that slash was more powerful than any weblog currently written in PHP. I hold to the opinion that pretty stinking good slash-type weblog can be created in PHP, if only enough quality effort would be thrown at it. And I think it can be done while still offering PHP-level ease of installation (download, untar/gz, create the db, put the settings in a config file/script, and run the install script. Viola. takes about 20 minutes for the whole kit and caboodle... from nothing whatsoever to now working on customizing it). I personally don't give a rip about some distribution that might have the right stuff already installed and configured for slash. Practically no web host is going to use that distribution anyway. Now if it gets into RedHat 8.0, then we're talking. Sure, I'd love it if more hosts used slack, deb, or whatever -real- distro <wink>, but they don't. So what do I or other cheap shared-host users care? My only point is to not misrepresent the situation of installing slash vs. installing anything else. It's easy to make it sound like it's all basically the same when it's not. As for saying that if a PHP slash-quality weblog would require the same sort of installation complexities as slash... well, whatever. Thanks for your time and ear, Joel |
From: Chris N. <pu...@po...> - 2001-04-23 15:18:53
|
At 09:53 -0500 2001.04.23, Joel Kleppinger wrote: >That's not the point. No self-respecting shared (or even dedicated) web >host isn't going to offer both mod_perl, mod_php, mysql and whatever >else. The difference is, for slash, you have to have recompile mod_perl >and possibly/probably apache as well. Only because they were not originally compiled to offer the users full functionality. >I know nothing I say or do will >change that because I understand the reasons for it. But don't shrug off >recompilations by saying "well everyone has to do it." I don't understand why not. If your Apache web server were compiled without CGI access, wouldn't you turn around and say, well, it should have been? That's what I am saying here. >> >Even though I don't know much perl, I believe that what is holding slash >> >back from being easier to install is the fact that perl just doesn't come >> >with all of those modules installed. >> >>Nope. Many of the things required here would be additional modules or code >>for PHP, too! The same reasons why you -- and pretty much everyone -- >>admits that Slash is so much more powerful than PHP* are the same reasons >>why we have external modules required. >> >I don't remember saying slash was more powerful than PHP. What I said was >that slash was more powerful than any weblog currently written in PHP. That is what "PHP*" means. >I hold to the opinion that pretty stinking good slash-type weblog can be >created in PHP, if only enough quality effort would be thrown at it. Sure. And to get to the Slash level of power, they would need to either write a ton of custom code, or they would need to include/depend on external code, which is what we do. >And I >think it can be done while still offering PHP-level ease of installation >(download, untar/gz, create the db, put the settings in a config >file/script, and run the install script. Viola. takes about 20 minutes >for the whole kit and caboodle... from nothing whatsoever to now working on >customizing it). That sounds exactly like the Slash installation process, to me. Takes about 20 minutes in my experience, even installing all the modules! Of course, that does not include rebuilding mod_perl/Apache, which is often not necessary anyway. >My only point is to not misrepresent the situation of installing slash vs. >installing anything else. I'm not. You brought up the other things, and I was answering to them. I am simply saying that Slash depends heavily on mod_perl, and if someone does not give you access to the full capabilities of mod_perl, there's nothing we can do about it ... unless, as I have asked before (and have not gotten any responses), someone can go in, find out what in Slash depends on what is not in Distribution X, so we can consider working around it. But I don't know what those things are, and don't have time to figure out. >As for saying that if a PHP >slash-quality weblog would require the same sort of installation >complexities as slash... well, whatever. Which installation complexities? The part about mod_perl? Well, if mod_php were hampered in its configuration, then maybe it would, I don't know. The part about modules? That can be recitifed, again, by ANYONE who wants to take the time to put the modules into a single distribution. As for the rest of the installation process, what you described as "PHP-level ease" is exactly how Slash 2 installs. You download, unpack, make, create the DB, run the install script, do a few configs. Done. At 09:53 -0500 2001.04.23, Joel Kleppinger wrote: >That's not the point. No self-respecting shared (or even dedicated) web >host isn't going to offer both mod_perl, mod_php, mysql and whatever >else. The difference is, for slash, you have to have recompile mod_perl >and possibly/probably apache as well. Only because they were not originally compiled to offer the users full functionality. >I know nothing I say or do will >change that because I understand the reasons for it. But don't shrug off >recompilations by saying "well everyone has to do it." I don't understand why not. If your Apache web server were compiled without CGI access, wouldn't you turn around and say, well, it should have been? That's what I am saying here. >>for PHP, too! The same reasons why you -- and pretty much everyone -- >>admits that Slash is so much more powerful than PHP* are the same reasons >>why we have external modules required. >> >I don't remember saying slash was more powerful than PHP. What I said was >that slash was more powerful than any weblog currently written in PHP. Yes, that is what "PHP*" meant. >I hold to the opinion that pretty stinking good slash-type weblog can be >created in PHP, if only enough quality effort would be thrown at it. Sure. And to get to the Slash level of power, they would need to either write a ton of custom code, or they would need to include/depend on external code, which is what we do. And as noted before, the additional modules have nothing to do with ease of installation. If someone really had a problem with having to install extra modules, they could put out a distribution with all of them included. >And I >think it can be done while still offering PHP-level ease of installation >(download, untar/gz, create the db, put the settings in a config >file/script, and run the install script. Viola. takes about 20 minutes >for the whole kit and caboodle... from nothing whatsoever to now working on >customizing it). That sounds like the Slash installation process, to me. You download, unpack, make, create the DB, run the install script, do a few configs. Done. Takes about 20 minutes in my experience, even with installing all the modules via the CPAN, which is a single command at the command line (perl -MCPAN -e 'CPAN::Shell->install("Bundle::Slash")'). Of course, that does not include rebuilding mod_perl/Apache, which is often not necessary anyway. >My only point is to not misrepresent the situation of installing slash vs. >installing anything else. I am simply saying that Slash depends heavily on mod_perl, and if someone does not give you access to the full capabilities of mod_perl, there's nothing we can do about it. That is hardly a fault of Slash or a feature of some other thing, it is the fault of whoever configured mod_perl to have it hampered. And, as I have asked before (and have not gotten any responses), someone can go in, find out what in Slash depends on that is not in Distribution X, so we can consider working around it. But I don't know what those things are that need to be worked around, and don't have available time to figure out. >As for saying that if a PHP >slash-quality weblog would require the same sort of installation >complexities as slash... well, whatever. Which installation complexities? The part about mod_perl? Well, if mod_php were hampered in its configuration, then maybe it would, I don't know. The part about modules? That can be recitifed, again, by ANYONE who wants to take the time to put the modules into a single distribution. As for the rest of the installation process, what you described as "PHP-level ease" is the same as how Slash 2 installs. -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
From: Joel K. <jkl...@ea...> - 2001-04-23 16:02:21
|
It was written: > >I know nothing I say or do will > >change that because I understand the reasons for it. But don't shrug off > >recompilations by saying "well everyone has to do it." > >I don't understand why not. If your Apache web server were compiled >without CGI access, wouldn't you turn around and say, well, it should have >been? That's what I am saying here. Curiously, how many CGI programs are there? thousands? hundreds of thousands? How many programs require the mod_perl compilation options? one? Last I checked, 90% of the people running shared hosts either A) weren't geniuses or B) were and charged an arm, a leg, and half your non-tech stock portfolio to do anything. So if it isn't in the distribution, it probably isn't on the host. Oh, and I was accounting for more of the general audience in estimating 20 minutes installation of a PHP weblog (however poor the coding of that log may be). I would expect (hope) that you could do it in 5 or less. Joel |
From: Chris N. <pu...@po...> - 2001-04-23 16:27:04
|
At 11:02 -0500 2001.04.23, Joel Kleppinger wrote: >Curiously, how many CGI programs are there? thousands? hundreds of >thousands? How many programs require the mod_perl compilation options? Thanks for proving my point. More people would complain if the bad configuration broke something popular. But just because the bad configuration affects something unpopular ... so? That is not a reflection on Slash or mod_perl. It is, nevertheless, a reflection on poorly configured systems. >Oh, and I was accounting for more of the general audience in estimating 20 >minutes installation of a PHP weblog (however poor the coding of that log >may be). I would expect (hope) that you could do it in 5 or less. No, it would take me a lot longer, since I don't have mod_php installed already, just like a lot of bad Apache builds don't have a good mod_perl configuration. Hm, since I don't have PHP installed, so Slash installation is much faster, does that mean the Slash installation is actually BETTER than a PHP* program's installation is? I think so. I am not sure why this is difficult to see. Yes, a lot of Apache/mod_perl configs are messed up and don't work out of the box with Slash. And yes, most people I know don't even have PHP installed and can use Slash out of the box with their configuration. Each is easier for some than for others. And I have nothing against trying to make it work better with these poorly configured mod_perl installations. But someone else needs to do the work of figuring out what needs to be changed, because I don't have the available time. -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
From: jesse h. <je...@ta...> - 2001-04-23 17:09:53
|
just wanted to jump in on this thread. its been interesting as a barometre of perception. i think the subject line touches upon many aspects, most noteably of course is the last acronym/word. in the last few months i've spent a considerable amount of time looking at web hosting companies and co-lo deals, etc., while at the same time have continued to run a number of servers under a number of different guises (tao.ca and openflows.org). in the case of the latter, we recently setup a server dedicated to running the slashcode, since so many of our clients wanted to run it (these are existing clients not new ones). in the course of which, we've also tinkered with the idea of offering "slash hosting" as it were, but are still unsure about pricing. our existing client base doesn't come to us for slash per se, but after working with us (around the internet in general), see what it is (in juxtaposition with other gnu apps) and want us to implement it for them. these people pay us by the hour, per project, and the hosting is pretty much free. we prefer to organize revenue according to our time, and absorb resources/facilities into that cost. it thus makes it difficult to think of pricing or services that focus just on hosting... the reason i like slash is because of the quality factor. its nice to see a gpl code make it to 2.0. a lot of the economics behind hosting companies is to do everything as cheaply as possible. reduce the costs, multiply the tools and space, charge as low as possible. i just think, especially post-dot-com-mania, that it makes more sense to go for the quality and complex over the quantity and simplicity. > >Oh, and I was accounting for more of the general audience in estimating 20 > >minutes installation of a PHP weblog (however poor the coding of that log > >may be). I would expect (hope) that you could do it in 5 or less. phpnuke.org is an obvious example. its really easy to install, comes with a ton of "themes" that make it easy to customize, and it has a large user base to contribute back fixes and add-ons etc. now with that said, i think it has serious limitations. the way i've explained it to people, is that phpnuke is written/maintained by hobbyists, while slashcode is written/maintained by professionals. in the former you get easy-to-install code, in the later you get robust and stable code. i found phpnuke to be too easy. like so easy it made it hard to really change. it made it hard to keep up with constant updates. it made it hard to keep up with a users email list with 100+ traffic a day, 99 of which was en route to /dev/null > No, it would take me a lot longer, since I don't have mod_php installed > already, just like a lot of bad Apache builds don't have a good mod_perl > configuration. i compile my apache with perl and php, and i'm sure i've got a relatively poor config ;) but the point is i do get it all working in the end. and honestly, i'm not much of a techie (writer and activist by trade) nor do i have the patience to rtfm, nonetheless i'm able to get code running, humming, and working just fine... last client (their own p3 server) we did apache, mysql, php/perl, slash, cpan... in definitely less than 20 mins 1:09pm up 11 days, 22:08, 11 users, load average: 0.04, 0.25, 0.31 |
From: Jim P. <ji...@ya...> - 2001-04-23 20:47:01
|
Joel, I challenge you to take as many CGI programs that you can find and use them to build a system compatable w/ Slash. Let's see if you can do that in 20 minutes. Seriously, what you are asking for in Slash (simplicity) is not going to be found in a *system* as complex as Slash is. It's just not going to happen. -Jim P. --- Joel Kleppinger <jkl...@ea...> wrote: > Curiously, how many CGI programs are there? thousands? hundreds of > thousands? How many programs require the mod_perl compilation > options? one? > Last I checked, 90% of the people running shared hosts either A) > weren't > geniuses or B) were and charged an arm, a leg, and half your non-tech > stock > portfolio to do anything. So if it isn't in the distribution, it > probably > isn't on the host. > > Oh, and I was accounting for more of the general audience in > estimating 20 > minutes installation of a PHP weblog (however poor the coding of that > log > may be). I would expect (hope) that you could do it in 5 or less. > > Joel > __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ |
From: Dave H. <da...@ho...> - 2001-04-23 15:43:09
|
Chris Nandor <pu...@po...> writes: > At 09:53 -0500 2001.04.23, Joel Kleppinger wrote: > >That's not the point. No self-respecting shared (or even dedicated) web > >host isn't going to offer both mod_perl, mod_php, mysql and whatever > >else. The difference is, for slash, you have to have recompile mod_perl > >and possibly/probably apache as well. > > Only because they were not originally compiled to offer the users full > functionality. Are we talking the "EVERYTHING=1" switch here? Or more? -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Interim CTO, web server farms, technical strategy ---------------------------------------- |
From: Chris N. <pu...@po...> - 2001-04-23 15:52:31
|
At 16:35 +0100 2001.04.23, Dave Hodgkinson wrote: >Chris Nandor <pu...@po...> writes: > >> At 09:53 -0500 2001.04.23, Joel Kleppinger wrote: >> >That's not the point. No self-respecting shared (or even dedicated) web >> >host isn't going to offer both mod_perl, mod_php, mysql and whatever >> >else. The difference is, for slash, you have to have recompile mod_perl >> >and possibly/probably apache as well. >> >> Only because they were not originally compiled to offer the users full >> functionality. > >Are we talking the "EVERYTHING=1" switch here? Or more? I am talking about anything that Slash relies on that is not available in some Distribution X. I don't know what those things are, since I know nothing about what mod_perl capabilites Distribution X has and has not provided. -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
From: Dave H. <da...@ho...> - 2001-04-23 16:09:44
|
Chris Nandor <pu...@po...> writes: > I am talking about anything that Slash relies on that is not available in > some Distribution X. I don't know what those things are, since I know > nothing about what mod_perl capabilites Distribution X has and has not > provided. It might be just a case of petitioning Doug McEachern to make your flags the default in the mod_perl tarball then a distro has to go out of its way to break it. Or getting some acoltyes herabouts to get the SRPM (or whatever), fix the flags and rebuild? Dave // Not a packages fan unless they really, really work. -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Interim CTO, web server farms, technical strategy ---------------------------------------- |
From: Chris N. <pu...@po...> - 2001-04-23 16:27:12
|
At 17:02 +0100 2001.04.23, Dave Hodgkinson wrote: >Dave // Not a packages fan unless they really, really work. So you aren't a packages fan at all, then? :-) -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
From: Dave H. <da...@ho...> - 2001-04-23 16:56:34
|
Chris Nandor <pu...@po...> writes: > At 17:02 +0100 2001.04.23, Dave Hodgkinson wrote: > >Dave // Not a packages fan unless they really, really work. > > So you aren't a packages fan at all, then? :-) Hehe, damn, outed. OK, how about a Slash distro with _only_ the things you need for Slash? Compiled properly? Um, oh, and with optional Athlon optimisations. Oh, forget it. -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Interim CTO, web server farms, technical strategy ---------------------------------------- |
From: Morbus I. <mo...@di...> - 2001-04-20 15:02:05
|
> 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". |
From: Brian A. <br...@ta...> - 2001-04-20 15:39:21
|
Might I suggest to just go with a slash hosting provider? -Brian |
From: Chris N. <pu...@po...> - 2001-04-20 16:14:59
|
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/ |
From: Morbus I. <mo...@di...> - 2001-04-20 18:49:19
|
>> 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. You know what, neither do I. I was on someone else's machine, and I had a yattering moron talking to me the whole time I was drafting the letter. I think I meant about CGI's not having root access, and module errors resulting in the call to the webhost. >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. Quite indeed. It's relatively easy to write an XML parser with regexps - it's not the greatest solution, but it's one that works. I always design crap with the minimal stuff first - all XML parsing would be layered so that if people did already have XML::Parser installed, they could just swap the library and be all set. I don't have a problem with modulated setups, but only if they're an afterthought <g>... >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 I actually haven't looked into the template-toolkit all that well, but the stupid people I work with every day as customers of the ISP wouldn't use (or understand) a complex template system (or rather, "a template system that would take months or years" to write). >>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 see what you're saying, but it doesn't gel perfectly in my head. The average user doesn't run their own webserver because they don't have the bandwidth or knowledge about static or dynamic IPs and name resolution. But the average user doesn't need to worry about that cos there are kazillions of providers out there that already provide web hosting (either per month, or free with their access). There aren't millions of hosters with Slash (or at least, not the same million), and if people are looking around for software that duplicates what Slash does, they're not going to find many viable/free examples. And yes, I realize that with a bit more thought, we can both find an example that proves your point with no rebuke by me. I know what you're point is, at this point, I'm playing devil's advocate. >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. I think, at this point, this is the most viable explanation I've heard, and is probably the point that will bounce around in my head the most. Thanks. Morbus Iff .sig on other machine. http://www.disobey.com/ http://www.gamegrene.com/ |
From: Chris N. <pu...@po...> - 2001-04-20 18:58:31
|
At 14:50 -0400 2001.04.20, Morbus Iff wrote: > >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. > >Quite indeed. It's relatively easy to write an XML parser with regexps - No, it isn't. It is quite difficult. XML is Hard to parse. Now, you could write something that could parse a _subset_ of XML, without too much difficulty. But it would not be an 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 > >I actually haven't looked into the template-toolkit all that well, but the >stupid people I work with every day as customers of the ISP wouldn't use >(or understand) a complex template system (or rather, "a template system >that would take months or years" to write). I don't think it would be a problem, really. Template is easier to use than HTML (I think). > >>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 see what you're saying, but it doesn't gel perfectly in my head. The >average user doesn't run their own webserver because they don't have the >bandwidth or knowledge about static or dynamic IPs and name resolution. But >the average user doesn't need to worry about that cos there are kazillions >of providers out there that already provide web hosting (either per month, >or free with their access). > >There aren't millions of hosters with Slash (or at least, not the same >million), and if people are looking around for software that duplicates >what Slash does, they're not going to find many viable/free examples. True. But what if there weren't millions of hosters out there with Apache? Would you still expect that a user should be able to FTP some files to a directory and run their own web server? That's the point: I know not everyone will allow Slash. But it is a system that makes a lot of assumptions about what is available -- even though it is very portable -- and you can't take those away easily. Have a great weekend, -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
From: Morbus I. <mo...@di...> - 2001-04-20 19:10:05
|
>>Quite indeed. It's relatively easy to write an XML parser with regexps - > >No, it isn't. It is quite difficult. XML is Hard to parse. Now, you >could write something that could parse a _subset_ of XML, without too much >difficulty. But it would not be an XML parser. LOL... ok. Here's another one of my accessibility snafu's. The XML I'd rather work with is non-attributed, non-namespaces, non-DTD'd, non-schema'd, bits of text... much like (idiotbox example) \r <name></name> <email></email> <number> <phone></phone> <fax></fax> </number> \r In which case, that is easy to parse and write out. Again, I go from a rather minimal approach and scale up, never the other way. >Have a great weekend, I shall try. The clouds are forming on the horizon (nothing to do with our conversations), and things may turn rather sour. Woeful sigh, nanu, nanu. Morbus Iff .sig on other machine. http://www.disobey.com/ http://www.gamegrene.com/ |
From: Ian S. <ia...@cs...> - 2001-04-20 18:14:55
|
"Morbus Iff" <mo...@di...> writes: > "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. i'm confused by this criterion. if the stupid user doesn't understand telnet, how are they going to understand CGI scripts? or blocks? or karma? i mean, even CT doesn't understand karma ;-) ian -- ---- Ian Soboroff ia...@cs... University of MD Baltimore County http://www.cs.umbc.edu/~ian |
From: Chris N. <pu...@po...> - 2001-04-20 18:27:19
|
At 14:11 -0400 2001.04.20, Ian Soboroff wrote: >or karma? i mean, even CT doesn't understand karma ;-) LOL! -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |