I agree that the best way forward is for someone to write a patch implementing the hooks. These hooks could be tested even on rewritten installs.
The plugin is best built and maintained by someone who does not use mod_rewrite, and will thus have a vested interest in keeping it up to date. Finally, some notes on the "debate" of mod_rewrite: People frequently cited web server statistics, but that's not the important part. The statistic we should be looking at is what percentage of servers which meet all our other requirements (PHP5, PDO, etc.) don't have mod_rewrite: I'm guessing it's much lower than 50%. When looking at support of technology, we want to be sure it will not hold the project back in any way. Supporting PHP4 would have done that, since then we couldn't use the beficial aspects of PHP5. I remain convinced adding hooks that could potentially support mod_rewrite won't do anything to hold the project back. We can still have all the front controller goodness, and most systems will be able to support almost everything we do with mod_rewrite anyways. On Jun 16, 2009, at 11:00 AM, Owen Winkler wrote: > > Realpolitik wrote: >> >> I feel like all of the comparisons to PHP4 are drastic >> overstatements. > > That's because it's not about what would be required to support the > feature, but the philosophical choice of developing only certain > avenues > explicitly to avoid the cost of others. > > There were many contributing factors to the choice, but the reason we > did not include PHP4 support in Habari was not primarily because it > would required many man-hours of development to include in addition to > PHP5. We did not include PHP4 support because we wanted to be more on > the forefront of development, and excluding the technology we didn't > want allowed us to focus more on what we did want. > > mod_rewrite is not legacy, but in the similar vein that PHP4 does not > support OOP well, non-mod_rewrite servers do not support the front > controller pattern that we preferred. So rather than developing with > the intent to support code we didn't want and would never use, we > chose > to rely on rewritten URLs. > > It's not a matter of comparative simplicity in development. It's a > choice to have the core do something only one way, the way we > wanted, well. > > I'm belaboring this discussion not because I particularly care about > mod_rewrite, but I think that understanding the motives of early-on > Habari development decisions is generally important for figuring out > what features and direction Habari takes in the future. > >> >> 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. > > The only person suggesting the exclusion of such plugins is you. > Please > review the thread, where even I said that including the hooks would > be fine. > > The problem you face is that I doubt any core developers will care to > write this code for you. And since none that I know of use > non-rewritten URLs, it may also be difficult for them to test > submitted > patches. Nonetheless, there are already core devs replying to the > thread that are supportive of a patch, including myself, especially if > the hooks are useful for more than just avoiding mod_rewrite. > > The energy put into this thread long ago exceeded writing the actual > code to implement its ideas. > > Owen > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
