On Mon, Mar 6, 2017 at 10:11 AM, Martin Bačovský
wrote:
> The current state is that the apipie cache consists of root index page and
> page per API resource and method and JSON desription of whole API
> (multiplied by number of languages). Currently we build all the resource
> specific pages duri
Guys if there's any doable way of getting rid of index generation or
making it significantly faster, that would be super useful.
LZ
On Mon, Mar 6, 2017 at 10:11 AM, Martin Bačovský
wrote:
> The current state is that the apipie cache consists of root index page and
> page per API resource and me
On Mar 6, 2017 11:11 AM, "Martin Bačovský"
wrote:
The current state is that the apipie cache consists of root index page and
page per API resource and method and JSON desription of whole API
(multiplied by number of languages). Currently we build all the resource
specific pages during the packag
The current state is that the apipie cache consists of root index page and
page per API resource and method and JSON desription of whole API
(multiplied by number of languages). Currently we build all the resource
specific pages during the package build time. The index and JSON need to
contain all
On Mon, Mar 06, 2017 at 10:46:18AM +0200, Ohad Levy wrote:
> On Mon, Mar 6, 2017 at 10:34 AM, Tomas Strachota
> wrote:
>
> > It's used for generating both html doc pages and json (consumed by
> > apipie bindings). We can't get rid of iterating over languages, but
> > generating docs only in json
On Mon, Mar 6, 2017 at 10:34 AM, Tomas Strachota
wrote:
> It's used for generating both html doc pages and json (consumed by
> apipie bindings). We can't get rid of iterating over languages, but
> generating docs only in json format and having html page that loads it
> async and generates the con
It's used for generating both html doc pages and json (consumed by
apipie bindings). We can't get rid of iterating over languages, but
generating docs only in json format and having html page that loads it
async and generates the content dynamically would probably bring the
desired speedup. I like
Perhaps, but AFAIK we generate index page in all supported i18ned
languages, so the process is somehow repeated 12 times which makes is
slow I believe.
LZ
On Fri, Mar 3, 2017 at 5:11 PM, Ewoud Kohl van Wijngaarden
wrote:
> On Fri, Mar 03, 2017 at 04:34:49PM +0100, Lukas Zapletal wrote:
>> the ra
On Fri, Mar 03, 2017 at 04:34:49PM +0100, Lukas Zapletal wrote:
> the rake apipie:cache:index command which we do both in build phase
> and after RPM package installation is slow as hell. What is the reason
> for that? Can't we redesign this to completely avoid need of
> generating this kind of ind
Hello,
the rake apipie:cache:index command which we do both in build phase
and after RPM package installation is slow as hell. What is the reason
for that? Can't we redesign this to completely avoid need of
generating this kind of index? For example the page could be
JavaScript based, plugins woul
10 matches
Mail list logo
