* Needing to create the albumimage "viewer" pages for each photo
seems like it will become a pain. Everyone will need to come up
with their own automation for it, and then there's the question
- of how to automate it when uploading attachments.
+ of how to automate it when uploading attachments. -J
> There's already a script (ikiwiki-album) to populate a git
> checkout with skeleton "viewer" pages; I was planning to make a
> on the implementation). I agree that this is ugly, though. -s
>> Would you accept a version where the albumimage "viewer" pages
->> could be 0 bytes long, at least until metadata gets added? -s
+>> could be 0 bytes long, at least until metadata gets added?
+>>
+>> The more I think about the "binaries as first-class pages" approach,
+>> the more subtle interactions I notice with other plugins. I
+>> think I'm up to needing changes to editpage, comments, attachment
+>> and recentchanges, plus adjustments to img and Render (to reduce
+>> duplication when thumbnailing an image with a strange extension
+>> while simultaneously changing the extension, and to hardlink/copy
+>> an image with a strange extension to a differing target filename
+>> with the normal extension, respectively). -s
* With each viewer page having next/prev links, I can see how you
were having the scalability issues with ikiwiki's data structures
- earlier!
+ earlier! -J
> Yeah, I think they're a basic requirement from a UI point of view
> though (although they don't necessarily have to be full wikilinks).
* And doesn't each viewer page really depend on every other page in the
same albumsection? If a new page is added, the next/prev links
may need to be updated, for example. If so, there will be much
- unnecessary rebuilding.
+ unnecessary rebuilding. -J
> albumsections are just a way to insert headings into the flow of
> photos, so they don't actually affect dependencies.
>>> have no idea what it depends on until the rebuild phase. -s
* One thing I do like about having individual pages per image is
- that they can each have their own comments, etc.
+ that they can each have their own comments, etc. -J
> Yes; also, they can be wikilinked. I consider those to be
> UI requirements. -s
album, but then anyone who can write to any other page on the wiki can
add an image to it. 2: I may want an image to appear in more than one
album. Think tags. So it seems it would be better to have the album
- directive control what pages it includes (a la inline).
+ directive control what pages it includes (a la inline). -J
> I'm inclined to fix this by constraining images to be subpages of exactly
> one album: if they're subpages of 2+ nested albums then they're only
etc. (Real pity we can't just put arbitrary metadata into the images
themselves.) This is almost pointing toward making the images first-class
wiki page sources. Hey, it worked for po! :) But the metadata and editing
- problems probably don't really allow that.
+ problems probably don't really allow that. -J
> Putting a JPEG in the web form is not an option from my point of
> view :-) but perhaps there could just be a "web-editable" flag supplied
> Replying to myself: perhaps best done as an orthogonal extension
> to attach? -s
+> Yet another non-obvious thing this design would need to do is to find
+> some way to have each change to memes/badger._albummeta show up as a
+> change to memes/badger in `recentchanges`. -s
+
Things that would be nice, and are probably possible:
* make the "Edit page" link on viewers divert to album-specific CGI instead