Many of you will just switch off because it's me spouting off again, but hopefully some of you will listen ...
The current discussion on http response objects and other aspects of the transmission process has brought out a few more 'what the ...' from some of you and as with a lot of the 'modern' discussions, the reasons for wanting something tend to be wrapped in a lot of assumptions that the rest of us understand exactly what is being discussed. In many cases I'll be frank - despite starting programming back in the early 1970's much of the debate goes over my head! 'http response objects' ... When I switched to using PHP over C/C++ we had something called prettyURL which the apache rewrite rules processed into a format the PHP would handle. Nowadays it is something like 'RESTFUL design' that is doing the same process? My own style of working is for modular software. It started when the tikiwiki code base was ported over to tikipro and rather than one humongous pile of code, each 'package' of functionality has it's own directory of specific code and uses the central core of common code. The url's have /wiki/, /contact/, /nlpg/ and the like and if a client needs a different style of contact, enquiry or task process it can be handled in isolation. Why is this relevant to the current discussion? Because it seems at odds with the basic way php-fig is designed with it's drive to centralization and when I've tried to apply their rules to my own code base it simply does not work. And wiping my neatly tab indented code is never going to convince me that THAT dictate is universally acceptable! Tabbed indenting goes far back even into Algol days and while the rules for C/C++ even in the PHP code base is TAB I'm not going to start being selective elsewhere! So I've not bothered even following the later PSR rules since simply starting adds hours to any code rework and I STILL have a lot of code which I've not found any help to automatically translate to clean (still 5.4 at this stage!) code. Moving forward, handling cookies seems to be another area where while some people feel they should be expunged from the internet, there is not a suitable alternative when handling the state of an anonymous visit? Nothing in the http traffic can be relied on to identify the visitor with even ip address changing from request too request, so we need to pass something back that can at least identify the client on subsequent requests? This is the area where traffic back and forth could perhaps be tidied up, but the question I still see no answer to is "Just what is it people think is broken and needs fixing?" With the current discussions on switching to a 'restful' interface to the TZDIST data, I can see that providing PHP with a cleaner way of using that format may be an advantage, but I don't see why one would move what is intended to be pure static content back into PHP? Once the package of data has been generated, it is cached at the http layer and modern tools like nginx handle it, only passing back to PHP when dynamic additions are required? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
