mirror of https://github.com/perkeep/perkeep.git
4fc061e8a2
To decide whether a search submitted to the app search proxy is allowed, we compare its results to the domain blobs, result of the master query, that we cache when the master query is set. However, since the results of the master query are liable to change when new blobs arrive (e.g. a new camliMember is added to the set that is published), that cache may need to be invalidated. Otherwise, we might reply with a 403 to search query that is actually allowed. Therefore, this CL adds a refresh of the cache on two instances: -When the app handler gets a search query that seems to be forbidden. Before replying with a 403, we refresh the cache with the master query, and recheck whether the search query is allowed. -When the publisher gets a request for a "members" page, or the "file" page, it preemptively asks the app handler to refresh. Now that a lot of the client workflow has been moved to javascript/the browser, these kinds of requests should not happen too often, so it seems a reasonable place to ask for a refresh. But this might change, so we should of course be careful not to flood the app handler with refresh requests in the future. In any case, the app handler is suppressing the refresh requests, so that it does not perform refreshes at more that one per minute. As a smarter approach, we could later imagine a way for the app handler to be aware of when new blobs get to the blobserver (akin to the blob hub that the sync handler uses?), so that it only ever refreshes when needed. Fixes #851 Change-Id: Idc14cce5018053deac01ec454e5c936ed93e5a05 |
||
|---|---|---|
| .. | ||
| example-blobs | ||
| json-signing | ||
| protocol | ||
| publishing | ||
| release | ||
| schema | ||
| todo | ||
| README.md | ||
| app-environment.md | ||
| arch.md | ||
| client-config.md | ||
| environment-vars.md | ||
| overview.md | ||
| overview.txt | ||
| principles.md | ||
| prior-art.md | ||
| release.txt | ||
| search-ui.md | ||
| search-ui.txt | ||
| server-config.md | ||
| sharing.md | ||
| status.md | ||
| terms.md | ||
| uses.md | ||
| web-ui-styleguide.md | ||
README.md
Documentation
- Overview: The original motivation and background for why Camlistore exists and what one might use it for.
For Users
If you're just looking to set up a Camlistore server and use it yourself, check out our getting started guide. The documents below go into more detail on customizing the high level configuration for use such as alternative blob storage or synchronization to cloud storage.
- Command-line tools
- Server Config: Details for configuring server storage and access, including synchronization to other Camlistore servers or backup to cloud storage providers
- Client config: Clients need this configuration file to securely connect to your Camlistore server(s)
For Developers
If you want to help the development of Camlistore or just want to know more about the how and why behind Camlistore, these docs are the going to help you get started. Something we didn't cover here that you're interested in? Ask on the mailing list.
Concepts
- Principles: our base principles, goals, assumptions
- Terminology: let's agree on terms to stay sane
- Use Cases: what one might do with all this (or at least our aspirations)
- Prior Art: other projects with similar goals or strategies
- Contributing: how to help
- Style guide for the Web UI
Technical Docs
- Packages: internal API documentation
- Architecture: the pieces, layers, and how they interact
- Schema: how we model data in Camlistore
- JSON Signing
- Sharing
Presentations
- 2016-04, GDG Seattle: [slides] [video]
- 2016-04, LinuxFest Northwest: [slides] [video]
- 2015-02, FOSDEM: [slides] [video]
- 2014-02, FOSDEM: [slides] [video] [WebM]
- 2013-06, Google Developers Live: [video]
- 2011-05, São Paolo Perl Conference: [slides]
- 2011-02, First Introduction: [slides]