[Interest] [Development] Qt installation prefix path issue

[Konstantin Tokarev]

25.10.2017, 23:56, "Thiago Macieira" <thiago.macieira at intel.com>:
> On Wednesday, 25 October 2017 13:32:29 PDT Christian Gagneraud wrote:
>>  On 25/10/2017 11:12 PM, Maurice Kalinowski wrote:
>>  > The reason is that code.qt.io is never meant as a public searchable
>>  > tool, but its purpose has always been to reduce the load on gerrit
>>  > when doing initial clones.
>>  >
>>  > Come on people, it's not that everything is meant to be purely evil,
>>  > but as code.qt.io is there since a while, its main use-case might
>>  > have shifted.
>>
>>  I'm not saying that everything is evil, i'm questioning if there is an
>>  intentional (or not) attempt at hiding things.
>
> Considering the contents of that website change very frequently, I'd assume
> that the reason is either that there's no point indexing something that
> becomes stale quickly or that they want to reduce the workload on the server
> caused by the indexing (remember: everything is generated).

It's possible to overcome this by enabling caching on reverse proxy server
(Apache in this case).

For "plain text" views CGit provides ETag header, which is a hash of file contents.
This header can be used for cache revalidation, and also good HTTP agents
witch cache will send it back on next access and get 304 instead of serving full file
contents. Given that a lot of files don't change e.g. during day, that should create
a huge load on server even if crawlers and users coming from search engines
start do more requests.

For "pretty" HTML views there seems to be no etags so they have to be regenerated
once in a while (every 5 minutes with current server settings).

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin