I am not against the inclusion of hooks that would allow for non rewrite operation, especially if it is only a job of a couple of hours. What someone needs to do, which is always the answer by the way, is craft something and submit it as a patch. Once we have a patch to test we can then see about getting it into trunk.
Speaking of patches, excuse me while I go and look through trac for some stuff to commit... On Jun 16, 2009, at 7:55 AM, Realpolitik wrote: > > Hopefully this will be my last post with the intent of convincing > anyone to add in hooks to allow for plugin-support for non mod_rewrite > installations. I like to question other people's reasoning, especially > when I disagree, but I do not feel strongly one way or the other about > this topic. I think it's unfortunate there isn't support for > mod_rewriteless systems, but this topic is wasting too much time to be > worthwhile for me and I feel like I keep getting dragged in to defend > something that I would never use. > > I feel like anyone reading from here on out should know that what is > being asked for by yugi and Arthus (and supported by me) is the > implementation of one or two hooks that enable a mod_rewriteless > plugin. This is no longer a discussion about whether to include native > support for non mod_rewrite servers into Habari. > > On Jun 15, 4:20 pm, Sean Coates <[email protected]> wrote: >> This is totally irrelevant unless we have core developers who use, >> develop, maintain and deploy Habari in non-mod_rewrite environments >> and who are willing to do the work to stay on top of this. > > This may be true if it were to be implemented as a core Habari > feature, but it would not be true if it's solely an add-on because > there are many simple ways to do this - ways that, once written > properly, are unlikely to break without a complete change in the > underlying structure. It should take an hour or two to develop and > test, you're right. But once you have a script that just uses > something as ugly as index.php/<the habari generated URL> you could > leave it alone without fear of breaking until there are major rewrites > to the plugin / Controller system. There are other ways to do this, > including splitting the request into values ?a&b&c, sending ?/a/b/c, > sending an encrypted URL index.php?a=3ddbe56389. In terms of long > term development costs, any issues that arise with new releases / > changesets should be visible after a 20 minute test session with the > url_rewriteless plugin. > > On Jun 15, 10:23 am, Owen Winkler <[email protected]> wrote: >> Perhaps. But while an underlying goal of Habari may be to extend its >> reach, it's not at the expense of introducing legacy/throwback >> technology. We specified PHP5 early on for that reason, and at the >> time >> that was seen as a detriment to Habari's reach also. >> >> I suspect that the GoPHP5 initiative, where developers simply cut off >> their own support of PHP4, had a lot to do with PHP5 acceptance >> across >> hosts. I would prefer to be driving change, rather than holding onto >> legacy for the sake of bigger installation counts. > > I feel like all of the comparisons to PHP4 are drastic overstatements. > I've only read ~20% of the Habari code at this point and only have a > good understanding of about 10% of it (meaning I've played around with > it directly, or toyed with creating a plugin/theme that did so). From > what I've seen it would require many changes to legacy (but still > functioning) methods instead of the updated methods used and object > workarounds - whether it be their loading, definition, or interaction > in order to achieve the same functionality. Providing PHP4 support in > a product that uses many PHP5 only features is a huge undertaking that > could not reasonably be done in a plugin and would in turn produce > numerous errors not just for those who use PHP4 but also those who use > PHP5. In addition, the performance would suffer because those > workarounds would be cumbersome. > > A simple fix to support up-to-date active servers like ISS and Sun or > Apache with users who do not have or do not want to use mod_rewrite is > a much smaller "project" and should take a few hours at most. The > errors would be self contained, and even if the developer(s) only use > the mod-rewrite for developing the mod_rewriteless plugin, any users > who experience issues could create a ticket, and that developer could > easily switch back to mod_writeless to reproduce the error and fix > it. > > If you want to take on a cause, take on the "say no to IE" cause and > just stop developing IE6 compatible website (I'd like that =D). The > supporting lack of mod_rewrite is not supporting legacy code, and not > using mod_rewrite is not an "old" style of web development. It's core > Apache functionality that is employed by nine out of the top ten > websites in the world based on traffic (though several of them do use > mod_rewrite for a subset of features). > > Excluding a plugin that would allow people to create mod_rewriteless > functionality for Habari is not championing a cause, and you will > affect nothing by it except a loss in users. If apache 2.4 comes out > and doesn't allow the characters ? or & to perform their functions and > instead forces everyone to split their variables up by /, then I would > say you shouldn't support the old method of accessing URLs and sending > GET variables because then you really would be affecting a change. As > it is, you're not pushing people towards the future, you're just > pushing people towards a different method -- when the alternate method > isn't used by IIS and other webservers, and when the alternate method > will exist for the next twenty years. > >> I can think of no practical reason - not reach-related - to avoid >> requiring mod_rewrite. > > There are no serious flaws introduced by mod_rewrite, this is true. > The only practical reason that isn't reach related would be if using a > non mod_rewrite version was faster, more reliable, and more secure. I > have not heard any convincing arguments that not using mod_rewrite > would increase performance in all three realms. The conversation has > always about reach and "ease of use" which harkens back to reach. > > It's simple to do, hurts no one, and provides lots of potential > benefit. Let the plugins sort out how they want to do it. > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
