Todolist for the first Canopy release

[abbysmal]

This issue will be about discussing the feature set expected for a first release of Canopy.

Features discussed

• Tags (header now supports the tags field, each tags separated by a ,)
• Sorting listing by date
• Multiple content type: see commit 07403c8
• Better error reporting: When a file can't be correctly parsed, respond to the hook http request something useful.
• Running on Xen
• Getting a release for pinned dependencies

I think I didn't forgot anything. If more features are needed, this is the right issue to discuss about them. :) (@avsm)

For the « Running on Xen » bit, @mmaker made sure it worked during the hackathon but i'm not too sure about the current status. Needs to try it again.

Also, before the release, it would be nice to have a release for some of the dependencies Canopy needs to pin in order to work.
The main culprit are currently:

• https://github.com/oklm-wsh/Decompress (@dinosaure is working on it and expects a release soon)
• (for Xen) dolog https://github.com/UnixJunkie/dolog.git#no_unix
• (for Xen) bin_prot https://github.com/samoht/bin_prot.git#112.35.00+xen
• (for Xen) crc https://github.com/yomimono/ocaml-crc.git#xen_linkopts

Pinging @samoht and @yomimono :-)

About the content type feature, the only thing needed is to find use cases for more of them. I am working on a irclog content type in order to display nicely the logs from the bi-monthly things discussed yesterday, as a first try.

I think everything is here, so feel free to discuss, and thanks to all of you for your feedbacks and your help during the development of Canopy! 💯

[hannesm]

@Engil many thanks for developing canopy (and of course @mmaker for bugfixes and xen stuff)! awesome project (minimal enough to let me actually use it and not being annoyed by writing web pages!)

[hannesm]

it would be great if I can store images (binary data) in the git repository, and address those easily in markdown (to embed images)...

[hannesm]

to run on xen, there's some irmin trouble (see mirage/irmin#348)

[dinosaure]

decompress is released 👍

[hannesm]

let me recollect from the MirageOS meeting notes

• in-place editing of content (GitHub lets you do that with markdown, but preview only changes, not entire page)
• language specific syntax highlighting (include https://highlightjs.org/)
• generation of atom feeds, filterable by tags.
• "blog format is ill-suited to general (non-time-ordered) content, but that's relatively simple to add" (I've no clue what would be needed to add? maybe templates for listings (or customized listing pages per directory?))

[hannesm]

hm, sorry for my ignorance @dinosaure, but which part of decompress is needed in irmin/git? (or why does it just work for me without decompress/irmin pins?)

[abbysmal]

It should work now without the decompress pin since it was released, I guess we forgot to update the doc. (so in your case I guess it takes the decompress version from opam, as installed when running mirage configure)
The old decompress release wasn't working with Canopy for some reasons I forgot, so we just pinned the repo. But now that a new version is released the pin isn't needed anymore. :)
(so your setup really is using Decompress (needed to unpack git pack files when pulling content on the repository), just not the pinned version)

[hannesm]

but nobody depends on decompress... I thought git would, but then I just read up on mirage/ocaml-git#145 and this isn't merged...

[hannesm]

ups, figured it is me who is stupid... it is applied here in canopy... sorry for the noise and confusion

[hannesm]

pinned stuff: irmin (since 0.11.0) does not depend on dolog anymore :) bin_prot-113.33.03 includes the xen patches (113.00.00+4.03 does not)... I guess the 'get it running on xen' is still wip (although I run it on xen)

[amirmc]

Is it time to do a release of canopy now? Version releases might make it a bit easier since canopy is already in use as a piece of the mirage infrastructure (so we should be using released versions via opam-repo).

[abbysmal]

Doing a release would be indeed great but I wonder what it implies for Canopy.
Installing it via Opam means that static files (which are still in use for TLS) would be compiled when installing the program, which seems to be complicated since generating the cert and key is something the user needs to do manually beforehand.
I can't thing of any solution for this right now and it seems that it pushes away the idea to do a proper release via opam, but I might be missing something easier than that. :)

[yomimono]

Just having some version tags might be sufficient. We can now express the version dependencies of Canopy in its config.ml as of Mirage 3.

[hannesm]

version dependencies are already in config.ml (for cohttp, decompress, tyxml) -- with ocaml/opam-repository#8613 getting merged we can adjust the tyxml constraint and can build without any pins :)

I don't really see the point in tagging Canopy: I use it multiple times with different configs (such as TLS certificates, logging host, IP configuration), and have a branch which I rebase on master whenever I feel like.

There should be some sort of mirage unikernel repository, but I'm still not sure which shape it should have.