Just want to make clear that I in no way was against adding those hooks in my previous post. I vote for adding hooks. Imho hooks cant hurt. Someone might even figure out some more fun stuff to do with those hooks. I for instance wrote Asciify using hooks that probably wasn't intended for doing exactly that and I know for a fact that no core devs are sweds so they definitly don't test what the hooks asciify uses does.
(Forgive my horrible english. Hopfully you get my reasoning anyway.) On Jun 16, 2:55 pm, Realpolitik <[email protected]> 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 -~----------~----~----~----~------~----~------~--~---
