It is indeed a folder uploaded with pk-put permanode. I will file a issue later tonight.
Sent from my phone > On 20 Aug 2018, at 17:19, Mathieu Lonjaret <[email protected]> wrote: > > Hi, > > In general, search queries in the web UI often do a "describe" of the > target, which basically indeed drills down into all the children (of > various relationship) of a target, so it knows how to display the > target more accurately (i.e. if it's a set, you want to display it as > a container with its children). So yeah, the large search response is > somewhat to be expected. However, in the context of the infinite > scrolling, I think we request only a window of the search results (of > e.g. only 1000 results), so there should be a cap on that response > size. > > That said, if you're really talking about directories (i.e. if you > uploaded a directory with pk-put -permanode), that's a different > particular case. I've redone the web UI aspect for it, and it would > not surprise me that it is sub-optimized. > > Can you clarify a bit more the use-case please, here or preferably in > a bug report (https://github.com/perkeep/perkeep/issues), so I know > what exactly to investigate? > > Cheers, > Mathieu > > >> On 20 August 2018 at 10:11, Viktor Ogeman <[email protected]> wrote: >> Adding on after some more testing, it seems also when i navigate back and >> forth that the results are not always cached, leading to navigating into the >> folder tree and back to the permanode a complete reload of the directory >> structure every time the permanode is visited. >> >> >>> On Monday, August 20, 2018 at 10:06:33 AM UTC+2, Viktor Ogeman wrote: >>> >>> Hi, >>> >>> When I do searches I get huge responses from the server (running >>> 2018-05-02), searching for "tag:bcp" for example it finds 13 permanode but >>> the response from the query endpoint of 20+Mb. Is this intentional? >>> >>> cURL ing the same request and looking at the response it look as if not >>> only information about the permanodes is sent from the server, but the >>> entire directory structures underneath them, which in particular for bcp's >>> can become unreasonably large (not usable on a slow or mobile connection) >>> >>> /Viktor >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Camlistore" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Perkeep" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Camlistore" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
