Optimize away most expensive file prune calls, when refreshing

[git.ikiwiki.info.git] / doc / plugins / contrib / album / discussion.mdwn

diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn
index a613bb2d232ed4f3d086aef4a706f575b6be575d..5c8e74fa6992966cc3a7e85741d244867a6eb8a0 100644 (file)
--- a/doc/plugins/contrib/album/discussion.mdwn
+++ b/doc/plugins/contrib/album/discussion.mdwn
@@ -76,6 +76,12 @@ code or tried it yet, but here goes. --[[Joey]]
 > though (although they don't necessarily have to be full wikilinks).
 > -s
 
 > though (although they don't necessarily have to be full wikilinks).
 > -s
 

+>> I think that with the new dependency types system, the dependencies for
+>> these can be presence dependencies, which will probably help with
+>> avoiding rebuilds of a page if the next/prev page is changed.
+>> (Unless you use img to make the thumbnails for those links, then it
+>> would rebuild the thumbnails anyway. Have not looked at the code.) --[[Joey]] 
+

 * 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
 * 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


@@ -97,6 +103,11 @@ code or tried it yet, but here goes. --[[Joey]]
 >
 > (This stalled my attempt at a trail plugin, too.) -s
 
 >
 > (This stalled my attempt at a trail plugin, too.) -s
 

+>> Not sure I understand why these need to look at pagespecs at scan time?
+>> Also, note that it is fairly doable to detect if a pagespec uses such
+>> metadata. Er, I mean, I have a cheezy hack in `add_depends` now that does
+>> it to deal with a similar case. --[[Joey]] 
+

 * One thing I do like about having individual pages per image is
   that they can each have their own comments, etc.
 
 * One thing I do like about having individual pages per image is
   that they can each have their own comments, etc.
 


@@ -131,6 +142,15 @@ code or tried it yet, but here goes. --[[Joey]]
 > page, so you can batch-edit the whole lot by editing one file (this
 > does mean that editing the album necessarily causes each of its viewers
 > to be rebuilt, but in practice that happens anyway). -s
 > page, so you can batch-edit the whole lot by editing one file (this
 > does mean that editing the album necessarily causes each of its viewers
 > to be rebuilt, but in practice that happens anyway). -s

+>
+>> Yes, that would make some sense.. It also allows putting one image in
+>> two albums, with different caption etc. (Maybe for different audiences.)
+>>
+>> It would probably be possible to add a new dependency type, and thus
+>> make ikiwiki smart about noticing whether the metadata has actually
+>> changed, and only update those viewers where it has. But the dependency
+>> type stuff is still very new, and not plugin friendly .. so only just
+>> possible, --[[Joey]] 

 
 ----
 
 
 ----
 


@@ -140,6 +160,10 @@ Suppose that each viewer is a JPEG-or-GIF-or-something, with extension
 ".albumimage". We have a gallery "memes" with three images, badger,
 mushroom and snake.
 
 ".albumimage". We have a gallery "memes" with three images, badger,
 mushroom and snake.
 

+> An alternative might be to use ".album.jpg", and ".album.gif"
+> etc as the htmlize extensions. May need some fixes to ikiwiki to support
+> that. --[[Joey]] 
+

 Files in git repo:
 
 * index.mdwn
 Files in git repo:
 
 * index.mdwn


@@ -172,6 +196,10 @@ To not confuse other plugins, album should probably have a filter() hook
 that turns .albumimage files into HTML? That'd probably be a reasonable
 way to get them rendered anyway.
 
 that turns .albumimage files into HTML? That'd probably be a reasonable
 way to get them rendered anyway.
 

+> I guess that is needed to avoid preprocess, scan, etc trying to process
+> the image, as well as eg, smiley trying to munge it in sanitize.
+> --[[Joey]] 
+

 do=edit&page=memes/badger needs to not put the JPG in a text box: somehow
 divert or override the normal edit CGI by telling it that .albumimage
 files are not editable in the usual way?
 do=edit&page=memes/badger needs to not put the JPG in a text box: somehow
 divert or override the normal edit CGI by telling it that .albumimage
 files are not editable in the usual way?


@@ -182,7 +210,14 @@ the overly strict constraint that the ordered sequence of pages in each
 album must be known at scan time. However, that's not *necessarily* needed:
 the album and each photo could collect an unordered superset of dependencies
 at scan time, and at rebuild time that could be refined to be the exact set,
 album must be known at scan time. However, that's not *necessarily* needed:
 the album and each photo could collect an unordered superset of dependencies
 at scan time, and at rebuild time that could be refined to be the exact set,

-in order. Perhaps restricting to "the images in an album A must match A/*"
+in order.
+
+> Why do you need to collect this info at scan time? You can determine it
+> at build time via `pagespec_match_list`, surely .. maybe with some
+> memoization to avoid each image in an album building the same list.
+> I sense that I may be missing a subtelty though. --[[Joey]] 
+
+Perhaps restricting to "the images in an album A must match A/*"

 would be useful; then the unordered superset could just be "A/*". Your
 "albums via tags" idea would be nice too though, particularly for feature
 parity with e.g. Facebook: "photos of Joey" -> "tags/joey and albumimage()"
 would be useful; then the unordered superset could just be "A/*". Your
 "albums via tags" idea would be nice too though, particularly for feature
 parity with e.g. Facebook: "photos of Joey" -> "tags/joey and albumimage()"


@@ -195,12 +230,20 @@ and it could get quite hard to navigate. Perhaps next/previous links could
 be displayed only for the closest ancestor (in URL space) that is an
 album, or something?
 
 be displayed only for the closest ancestor (in URL space) that is an
 album, or something?
 

+> Ugh, yeah, that is a problem. Perhaps wanting to support that was just
+> too ambitious. --[[Joey]] 
+

 Requiring renaming is awkward for non-technical Windows/Mac users, with both
 platforms' defaults being to hide extensions; however, this could be
 circumvented by adding some sort of hook in attachment to turn things into
 a .albumimage at upload time, and declaring that using git/svn/... without
 extensions visible is a "don't do that then" situation :-)
 
 Requiring renaming is awkward for non-technical Windows/Mac users, with both
 platforms' defaults being to hide extensions; however, this could be
 circumvented by adding some sort of hook in attachment to turn things into
 a .albumimage at upload time, and declaring that using git/svn/... without
 extensions visible is a "don't do that then" situation :-)
 

+> Or extend `pagetype` so it can do the necessary matching without
+> renaming. Maybe by allowing a subdirectory to be specified along
+> with an extension. (Or allow specifying a full pagespec,
+> but I hesitate to seriously suggest that.) --[[Joey]] 
+

 Ideally attachment could also be configured to upload into a specified
 underlay, so that photos don't have to be in your source-code control
 (you might want that, but I don't!).
 Ideally attachment could also be configured to upload into a specified
 underlay, so that photos don't have to be in your source-code control
 (you might want that, but I don't!).