A basic interface

[futurepaul]

Been thinking a bit about what this most minimal tool can look like (from the publishing perspective). Please mentally replace "blogify" with something much better:

blogify init

Creates public / private keypair

Stores blog metadata in .config/blogify/site_name.toml:

• Site name
• Base URL
• Author
• Local folder for storing posts
• Public key
• Any info needed for deployment

Stores private key somewhere!

blogify my_cool_post.html image1.jpg image2.png

(maybe could do the image include automatically but that's some extra parsing during this step)

Creates my_cool_post.post zip file in predefined post storage folder.

my_cool_post.post

• meta.toml
  • post title
  • author
  • date published
  • last modified
• my_cool_blog.html
• assets/
  • image1.jpg
  • image2.png
• signature.txt

blogify publish

Creates the .html, .post, and the redirect version of each post, then pushes them to the configured server.

You're done!

I'm probably leaving off some details, but this is the basic shape I'm thinking of.

[hedgehog-online]

Good thoughts on the blog side of things - I've been primarily focusing on the posts right now. Interesting model with blog information being stored in .config and usable globally, streamlines adding new posts.

"blogify init" gives me git init vibes, so blogs being their separate independent folders. Then, the blog post workflow assuming everything is mostly static would be:

1. Package a blog post
2. Put .post file in blog folder/posts/new_post.post
3. Run the blog generator to add the post to RSS, archive, etc.

Your way would be more convenient for actually working with these tools, rather than writing scripts - I'm going to think about this some more. I think it might be best to just have both - perhaps the .config for the blog managing tool could have the paths to blogs that the user manages, while the actual blogs are their own independent folders, this way we might be able to get the best of both worlds.

Also, for blog posts, so far with what I'm testing I've been just creating blog post .post files manually, and the blog post packaging command would just generate the checksums and then zip everything up - I thought it's more convenient to just point to a folder rather than to every individual file that needs to be put in the archive. With that in mind I should add a blogpost new command or something like that that would generate a skeleton for the blogpost.

[futurepaul]

I'm playing around a bit with this in blogify because apparently I can't handle prototyping outside of Rust!

Perhaps the best way forward right now is for us to work in independent implementations and reconcile them until we're compatible. That's sort of like a design process, yes?

Also: now that I read your last para I realize how silly it is to specify each file, I can just point at a folder.

Btw: when someone makes a blog post on their computer and they add images to it... are we expecting them to set good image urls at that point (like keep the images in the same folder as the .html, or in a ./assets folder) or are we going to track those images down for them and pull them in?

[hedgehog-online]

Independent implementations are a nice idea, let's do it.

For images, I think they should just be in the same folder or ./assets, for now on a goodwill basis, maybe with a very simple regex checker that gives a warning. Could probably elevate it to be a hard error - given that down the line .post files should be completely standalone.