web commit by tuomov

[git.ikiwiki.info.git] / doc / todo / blogging.mdwn

diff --git a/doc/todo/blogging.mdwn b/doc/todo/blogging.mdwn
index 2451a571370ea52a11dc675f6bb86b72467646a9..f9037b06370232e27e768581ef772060486646b1 100644 (file)
--- a/doc/todo/blogging.mdwn
+++ b/doc/todo/blogging.mdwn
@@ -1,6 +1,3 @@
-- The [[TODO]] page would work better if the first N were shown in full, 
-  and then all open items were shown in summary. Maybe add this mode.
-- Add Discussion and Edit links at the bottom of each inlined post.

 - It would be possible to support rss enclosures for eg, podcasts, pretty easily. 
 
 Here is the last of those items. Using the meta plugin you can give the appropriate 
 - It would be possible to support rss enclosures for eg, podcasts, pretty easily. 
 
 Here is the last of those items. Using the meta plugin you can give the appropriate 


@@ -8,27 +5,27 @@ info, and the enclosure will be added to the entry. It will also add a <link />
 at the top, but I don't know if this is necessary. It also includes a fix for
 when make is used without PREFIX. 
 
 at the top, but I don't know if this is necessary. It also includes a fix for
 when make is used without PREFIX. 
 

-http://jameswestby.net/scratch/podcast.diff
+<http://jameswestby.net/scratch/podcast.diff>

 
 -- JamesWestby
 
 
 -- JamesWestby
 

-       Hmm. Not quite how I'd envisioned podcasts would work, my idea was
-       more that the sound files would be kept inside the wiki, and the
-       inline plugin could be told to eg, inline *.mp3, and would add
-       those to the rss feed as enclosures. Maybe you'd also inline some
-       regular blog pages to describe the files or the like.
+> Hmm. Not quite how I'd envisioned podcasts would work, my idea was
+> more that the sound files would be kept inside the wiki, and the
+> inline plugin could be told to eg, inline *.mp3, and would add
+> those to the rss feed as enclosures. Maybe you'd also inline some
+> regular blog pages to describe the files or the like.

 
 

-       Do you think that would work or that it's worth pursuing that
-       approach? I haven't looked at podcasts enough to know if that
-       method would be technically feasable; for one thing it would limit
-       the blog items for podcasts to just having an enclosure but no
-       description.
+> Do you think that would work or that it's worth pursuing that
+> approach? I haven't looked at podcasts enough to know if that
+> method would be technically feasable; for one thing it would limit
+> the blog items for podcasts to just having an enclosure but no
+> description.

 
 

-       Even if that doesn't work and pages are needed to desribe the items
-       like you did, it still seems better to keep the podcast items in
-       the wiki..
+> Even if that doesn't work and pages are needed to desribe the items
+> like you did, it still seems better to keep the podcast items in
+> the wiki..

 
 

-       --[[Joey]]
+> --[[Joey]]

 
 That's fair enough. I'm a little unsure of how it all works, so I just did the
 simplest thing I could. 
 
 That's fair enough. I'm a little unsure of how it all works, so I just did the
 simplest thing I could. 


@@ -46,18 +43,18 @@ want to add a dependency on a IDv3 tag library. You could add another file
 
 It's obviously up to you which way you want to go.
 
 
 It's obviously up to you which way you want to go.
 

-http://jameswestby.net/scratch/podcast2.diff
+<http://jameswestby.net/scratch/podcast2.diff>

 
 -- JamesWestby
 
 
 -- JamesWestby
 

-       Hmm, this could be taken a step further, and assume that if
-       IkiWiki::pagetype doesn't return a defined page type for the page
-       in the blog, then no matter the extension it should be fed into the
-       rss feed in an enclosure. This would allow for not only podcasting,
-       but vidcasting and a form of photo blogging. Or even an rss feed
-       containing the source of ikiwiki. ;-)
-       
-       --[[Joey]]
+> Hmm, this could be taken a step further, and assume that if
+> IkiWiki::pagetype doesn't return a defined page type for the page
+> in the blog, then no matter the extension it should be fed into the
+> rss feed in an enclosure. This would allow for not only podcasting,
+> but vidcasting and a form of photo blogging. Or even an rss feed
+> containing the source of ikiwiki. ;-)
+> 
+> --[[Joey]]

 
 Yes I agree that this would be great, but rss2 spec says that enclosure
 must have mime-type. How about I use the File::MimeInfo trick from the 
 
 Yes I agree that this would be great, but rss2 spec says that enclosure
 must have mime-type. How about I use the File::MimeInfo trick from the 


@@ -70,3 +67,65 @@ this mode is used. It might be that this is not necessary, as can we assume
 that people wont use raw if they want to pod/vid/whatevercast?
 
 -- JamesWestby
 that people wont use raw if they want to pod/vid/whatevercast?
 
 -- JamesWestby

+
+> Using File::Mimeinfo makes sense to me.
+
+> I think it probably makes sense to make the (html) blog page
+> add an entry with a link to the file that's in the enclosure in the
+> rss feed. Whether or not raw is being used.
+
+> Note: I'm still unsure about whether podcasts should support
+> descriptions for the enclosures or not. Here's an early podcast
+> that did use descriptions:
+> <http://static.userland.com/gems/backend/gratefulDead.xml>
+> Here's a contemporary podcast, which also uses descriptions:
+> <http://www.lugradio.org/episodes.rss>
+
+> The podcast client I use certianly doesn't care about the
+> descriptions. But it's podracer, probably not the thing most
+> podcast users use. :-)
+
+> --[[Joey]]
+
+I tested with amarok, and that also ignored the description.
+I am thinking of those where you have a mixed feed, and people
+using clients that ignore enclsures get pretty much a blank post,
+with just the filename, and the html page, which also just displays
+the filename.
+
+I don't think this is a big issue though, so I guess it's just which
+you think is the cleaner interface.
+
+I have also added the first of your ideas as well (though you seem to have
+removed it). It adds a parameter to inline `archive_after` which limits
+showing full entries to that number.
+
+<http://jameswestby.net/scratch/limit.diff>
+
+-- JamesWestby
+
+> I removed it because I don't really see the need for it anymore.
+> The added complexity doesn't seem worth it, unless someone needs the
+> features. --[[Joey]]
+
+And here is the updated podcast patch supporting any file type.
+
+<http://jameswestby.net/scratch/podcast2.diff>
+
+-- JamesWestby
+
+And here is a patch for the remaining item. It adds links to the bottom of
+inlined entries for edit and discuss (if they are enabled). It doesn't add
+links for edit if the filetype is not known. 
+
+The stylesheet should probably be done slightly better than I have. I just
+added a bit of spacing as the links were too close to the date. I have no
+skill in this area though. Perhaps you would like to use the list system 
+that you have for the links at the top.
+
+<http://jameswestby.net/scratch/actions.diff>
+
+-- JamesWestby
+
+> Thanks! I did tweak the css a bit. Not totally happy with it, but pretty
+> good I think. (I'll try to get to the other patches soon.) --[[Joey]]