aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorJoey Hess <joey@gnu.kitenet.net>2009-09-30 15:17:03 -0400
committerJoey Hess <joey@gnu.kitenet.net>2009-09-30 15:17:03 -0400
commitcaa3818effe74c52fc783e31c51f0566c7805e62 (patch)
tree4242d3d8507a930b746e58d5ad37ebd310b86e47 /doc
parent2aa93377e8845b4dd19af5a470e270c23e4e7e15 (diff)
downloadikiwiki-caa3818effe74c52fc783e31c51f0566c7805e62.tar
ikiwiki-caa3818effe74c52fc783e31c51f0566c7805e62.tar.gz
thoughts
Diffstat (limited to 'doc')
-rw-r--r--doc/plugins/contrib/album/discussion.mdwn33
1 files changed, 33 insertions, 0 deletions
diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn
index 7a3c19cf6..5fb91c5a4 100644
--- a/doc/plugins/contrib/album/discussion.mdwn
+++ b/doc/plugins/contrib/album/discussion.mdwn
@@ -51,3 +51,36 @@ i'm new to ikiwiki, apologies if this is dealt with elsewhere. -brush
> This plugin is pretty ambitious, and is unfinished, so I'd recommend
> playing with a normal IkiWiki installation for a bit, then trying
> out this plugin when you've mastered the basics of IkiWiki. --[[smcv]]
+
+----
+
+You had wanted my feedback on the design of this. I have not looked at the
+code or tried it yet, but here goes. --[[Joey]]
+
+* 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.
+* With each viewer page having next/prev links, I can see how you
+ were having the scalability issues with ikiwiki's data structures
+ earlier!
+* 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.
+* One thing I do like about having individual pages per image is
+ that they can each have their own comments, etc.
+* Seems possibly backwards that the albumimage controls what album
+ an image appears in. Two use cases -- 1: I may want to make a locked
+ 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).
+* Putting a few of the above thoughts together, my ideal album system
+ seems to be one where I can just drop the images into a directory and
+ have them appear in the album index, as well as each generate their own wiki
+ page. Plus some way I can, later, edit metadata for captions,
+ 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.