doc/todo/blogging.mdwn

   1 - It would be possible to support rss enclosures for eg, podcasts, pretty easily.
   2
   3 Here is the last of those items. Using the meta plugin you can give the appropriate
   4 info, and the enclosure will be added to the entry. It will also add a <link /> tag
   5 at the top, but I don't know if this is necessary. It also includes a fix for
   6 when make is used without PREFIX.
   7
   8 <http://jameswestby.net/scratch/podcast.diff>
   9
  10 -- JamesWestby
  11
  12 > Hmm. Not quite how I'd envisioned podcasts would work, my idea was
  13 > more that the sound files would be kept inside the wiki, and the
  14 > inline plugin could be told to eg, inline *.mp3, and would add
  15 > those to the rss feed as enclosures. Maybe you'd also inline some
  16 > regular blog pages to describe the files or the like.
  17
  18 > Do you think that would work or that it's worth pursuing that
  19 > approach? I haven't looked at podcasts enough to know if that
  20 > method would be technically feasable; for one thing it would limit
  21 > the blog items for podcasts to just having an enclosure but no
  22 > description.
  23
  24 > Even if that doesn't work and pages are needed to desribe the items
  25 > like you did, it still seems better to keep the podcast items in
  26 > the wiki..
  27
  28 > --[[Joey]]
  29
  30 That's fair enough. I'm a little unsure of how it all works, so I just did the
  31 simplest thing I could.
  32
  33 You don't need a description for podcasts it seems. So there's nothing stopping
  34 you there.
  35
  36 I have another patch that I think does what you want. It only supports .mp3 files,
  37 .ogg or similar could be added easily.
  38
  39 It has the disadvantage that the filename is all there is to go on, as I can't
  40 think of a way to associate any information with the mp3 file. I don't
  41 want to add a dependency on a IDv3 tag library. You could add another file
  42 .mp3.info with the title/description in.
  43
  44 It's obviously up to you which way you want to go.
  45
  46 <http://jameswestby.net/scratch/podcast2.diff>
  47
  48 -- JamesWestby
  49
  50 > Hmm, this could be taken a step further, and assume that if
  51 > IkiWiki::pagetype doesn't return a defined page type for the page
  52 > in the blog, then no matter the extension it should be fed into the
  53 > rss feed in an enclosure. This would allow for not only podcasting,
  54 > but vidcasting and a form of photo blogging. Or even an rss feed
  55 > containing the source of ikiwiki. ;-)
  56 >
  57 > --[[Joey]]
  58
  59 Yes I agree that this would be great, but rss2 spec says that enclosure
  60 must have mime-type. How about I use the File::MimeInfo trick from the
  61 first patch to do this? I don't know why I didn't do this before.
  62 This will probably clean the code up a little as well.
  63
  64 What do you think of the change that when using raw, if the filetype is not
  65 known it adds an entry anyway? I did this so that the entries appear if
  66 this mode is used. It might be that this is not necessary, as can we assume
  67 that people wont use raw if they want to pod/vid/whatevercast?
  68
  69 -- JamesWestby
  70
  71 > Using File::Mimeinfo makes sense to me.
  72
  73 > I think it probably makes sense to make the (html) blog page
  74 > add an entry with a link to the file that's in the enclosure in the
  75 > rss feed. Whether or not raw is being used.
  76
  77 > Note: I'm still unsure about whether podcasts should support
  78 > descriptions for the enclosures or not. Here's an early podcast
  79 > that did use descriptions:
  80 > <http://static.userland.com/gems/backend/gratefulDead.xml>
  81 > Here's a contemporary podcast, which also uses descriptions:
  82 > <http://www.lugradio.org/episodes.rss>
  83
  84 > The podcast client I use certianly doesn't care about the
  85 > descriptions. But it's podracer, probably not the thing most
  86 > podcast users use. :-)
  87
  88 > --[[Joey]]
  89
  90 I tested with amarok, and that also ignored the description.
  91 I am thinking of those where you have a mixed feed, and people
  92 using clients that ignore enclsures get pretty much a blank post,
  93 with just the filename, and the html page, which also just displays
  94 the filename.
  95
  96 I don't think this is a big issue though, so I guess it's just which
  97 you think is the cleaner interface.
  98
  99 I have also added the first of your ideas as well (though you seem to have
 100 removed it). It adds a parameter to inline `archive_after` which limits
 101 showing full entries to that number.
 102
 103 <http://jameswestby.net/scratch/limit.diff>
 104
 105 -- JamesWestby
 106
 107 > I removed it because I don't really see the need for it anymore.
 108 > The added complexity doesn't seem worth it, unless someone needs the
 109 > features. --[[Joey]]
 110
 111 And here is the updated podcast patch supporting any file type.
 112
 113 <http://jameswestby.net/scratch/podcast2.diff>
 114
 115 -- JamesWestby
 116
 117 And here is a patch for the remaining item. It adds links to the bottom of
 118 inlined entries for edit and discuss (if they are enabled). It doesn't add
 119 links for edit if the filetype is not known.
 120
 121 The stylesheet should probably be done slightly better than I have. I just
 122 added a bit of spacing as the links were too close to the date. I have no
 123 skill in this area though. Perhaps you would like to use the list system
 124 that you have for the links at the top.
 125
 126 <http://jameswestby.net/scratch/actions.diff>
 127
 128 -- JamesWestby
 129
 130 > Thanks! I did tweak the css a bit. Not totally happy with it, but pretty
 131 > good I think. (I'll try to get to the other patches soon.) --[[Joey]]
 132
 133
 134 ---
 135
 136 I'm very happy to report that this is [[todo/done]]. Podcasting patch
 137 applied (finally!) --[[Joey]]