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