I've also started something which I think might help you with your end goal:
https://camlistore-review.googlesource.com/8188 On 21 August 2016 at 05:17, Erik Paulson <[email protected]> wrote: > I think I've got a pretty good handle on how data is modeled in camlistore, > with blobs, metadata blobs, permanodes, and claims building a graph > stitching it all together, ala git. > > I'm still a little bit confused by data is expected to flow in and out of > camlistore, between apps, handlers, importers, and the UI. (I do understand > that this part of camlistore is still a work in progress) > > The use case I was trying to do today was basically just webserving. I > wanted to take a directory, load it into camlistore, and then serve those > files via HTTP. I tried: > > mkdir junk > echo "first" >stuff/first.txt > echo "second" >stuff/second.txt > > camput file --permanode stuff/ > > Then, in the UI, I added an claim to the stuff/ permanode to set camliRoot > to 'junkRoot' > > Then, in my server-config.json, I added: > > publish: { > "/stuff/": { > "camliRoot": "stuffRoot", > "goTemplate": "gallery.html" > } > } > > and restarted camlistored. I tried to not specify a goTemplate, but it > insisted on having that key present. (I tried setting "goTemplate": "" but > no dice there, either) > > I was hoping that I'd be able to get localhost:3179/stuff/first.txt with > this setup, but no go. > > First, in order to get anything to show up under localhost:3179/stuff/, I > couldn't just have the file schema blobs as camliMembers of my 'stuff' > permanode the way camput created it- I had to create permanodes for > first.txt and second.txt and add those refs as camliMembers to the stuff > permanode. > > Second, it renders everything some entries in the gallery template. I guess > that's not surprising since I told it to use the gallery. Camlistore doesn't > have a way of knowing that I didn't actually want to set that config > entry... > > Finally, it does eventually give me a link to my file, but it's buried in a > URL like: > http://localhost:3179/stuff//-/hd27fc6a636/hb174f6a39c/=f/first.txt > > (I saw Mathieu's warning about the publisher being in progress in the latest > code, so this is all against master checked out here: > >> commit ce8b329d1d62a4ff6ab87812f657914ae7625f6d >> Author: mpl <[email protected]> >> Date: Thu Jun 23 16:07:57 2016 +0200 >> website: update CLA instruction >> >> Change-Id: I399ad44a0ebdeff05efd1dabb3137299b01f112b > > > Is there a way to make the 'publisher' app just serve up files directly with > a more regular httpd dirlisting sort of view? Is there a legacy handler that > I could use? (I'm not super-keen on mounting this in FUSE and serving that > way, but if that's the answer, so be it) > > I understand that many of the handlers and importers will be moving out of > bin/camlistored and into separate app processes, and camlistored will become > more like systemd/init/inetd in that it watches child processes and directs > traffic to and from those children. Do you have targets for other apps that > might be written? > > Is it expected that users will use 3rd party apps or write their own apps as > regular operation, or is it more that anyone who writes an app will do so > with the eventual intention of getting it included in the regular camlistore > repo and releases? Is there a reason to prefer running an app under > camlistored vs spawning my own process next to camlistored? > > My eventual use case is that I want to use camlistore as a host for a blog > generated by a static site generator like pelican or jeykll - besides > storing and serving the static HTML created by pelican, I want to write a > plugin to pelican to insert the permanode id for the post into the HTML > metadata about the page, so even if URL changes some day, the permanode > gives a really great rel=canonical opportunity in a decentralized world. For > this, I was hoping to use no code outside of camlistore for the actual > serving - camlistore would take care of the naming, and if a big file is > chunked by the rolling checksum into multiple blobs, the > publisher/handler/whatever takes care of reassembling the parts. > > Are "publishers" a first-class concept, or is it just that the only real app > going right now is the publisher, and having multiple "publishers" is really > just running the same app multiple times, pointed at different camliRoots > and using different HTML templates? If my only option is to write my own > code to serve dirlisting files, is it more correct for me to say I'm writing > my own "app" or I am writing my own "publisher"? > > I apologize if I'm not entirely clear in my email, and for asking so many > questions. > > Thanks, > > -Erik > > -- > 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 "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.
