Jyri Virkki wrote: > ludo wrote: > >> not sure if it is part of file layout area or not, but I noticed a few >> things we could add automatically on disk to ease the developer >> experience (based on the coolstack content): >> > > Hi Ludo, > > >> 1/ a favicon.gif file in htdocs of apache to avoid useless entries of >> 404 or file not found in the logs. OpenSolaris logo? >> 2/ a better index.html (and maybe more files for samples) to describes >> 'what' works when 'it works'. >> > [...] > > Some of the things you listed are easy details (I don't imply only > those two, just didn't want to quote everything), I encourage you to > file RFEs in solaris/utility/apache to track making those changes so > they are not forgotten in piles of email. >
You are correct about the details, but I think we need to pay more attention to these little things, very easy to fix/address, to achieve the developer experience we want. RFE is too weak imo. Does the solaris.utility/apache bug category cover the SAMP integration we are working on? I can start using it if this is the case. Does File layout spec cover the htdocs content? > For the more encompassing changes, please start individual discussion > threads here. > > >> Also, I've seen a few threads regarding the web-stack 'optimal' >> performance and flag settings, but I thing we need to discuss how we set >> these flags and options with 2 point of views: >> 1/ the Developer (our SAMP target I think): >> - no real need for added performance tuning >> - for example, saving a php file, and page reload on the browser must >> work without restarting apache:) >> - log managment (on, of, rotation, view,...) >> 2/ the Deployer of an AMP app >> - management flags >> - optimal Solaris performance. >> How do we balance these 2 conflicting roles in SXDE? Comments welcome, >> > > As much as I like to drive ultimate performance, if there is a > conflicting requirement for the default install, IMO it should favor > developer convenience. I suspect the default config will target > developers from day zero until small deployments. In more established > deployments there is always a need for customization of configurations > or even server software so initial defaults can't address everything. > Good to read, I concur Thanks, Ludo > (Ideally there should be no such conflicts and server software should > adjust automatically and that should be the long term goal. But in the > shorter term there are probably compromises.) > > >
