Both the new sourceRoot option works for me to be able to override gallery.html at runtime, and files are served with MIME types set so hitting a jpg gets displayed right in the browser - thanks!
-Erik On Wed, Aug 31, 2016 at 7:10 PM, Mathieu Lonjaret < [email protected]> wrote: > 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. > -- 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.
