* Rewritten rst plugin by madduck is a python program that communicates with

[git.ikiwiki.info.git] / doc / todo / fileupload / soc-proposal / discussion.mdwn

diff --git a/doc/todo/fileupload/soc-proposal/discussion.mdwn b/doc/todo/fileupload/soc-proposal/discussion.mdwn
index a24f70c51cdc1552e55c6ec53f9b7d70e1825566..299dc4c565f908c7f2de1c87bd45edd32d08b2c3 100644 (file)
--- a/doc/todo/fileupload/soc-proposal/discussion.mdwn
+++ b/doc/todo/fileupload/soc-proposal/discussion.mdwn
@@ -8,10 +8,39 @@ It's not clear to me that the concept of attaching files to a page fits ikiwiki
 
 >> I'd suggest `some-dir/some-page/file`, which nicely makes clear that the file is "attached" to some-page, allows easy wikilinks to "file" from some-page, and has other nice properties.
 
 
 >> I'd suggest `some-dir/some-page/file`, which nicely makes clear that the file is "attached" to some-page, allows easy wikilinks to "file" from some-page, and has other nice properties.
 

+>>> So _some-dir/some-page_ would feature an upload form that stored its payload in _some-dir/some-page/file_? IOW, we'd still be attaching files, but making the relationship between attacher and attached more explicit? --Ben
+
+>>>> More explicit or less, I don't know.. :-) It seems to make sense for most of the use cases I've thought of to put the uploaded file there, but there might be use cases where it would go somewhere else, and so maybe the UI should allow specifying where it goes (similarly to how ikwiki allows specifying where to put a page when creating a new page).
+
+>>>> Exactly where the upload form should be I don't know. Putting it directly on the page seems somewhat strange, I know that some wikis have an actions menu that includes file upload and deletion, I think others make the Edit form include support for uploading files. Maybe survey other wikis and base it on a UI that works well.
+

 > As for the attachment list, I envisaged that being optional. --Ben
 
 >> So some kind of preprocessor directive that is added to a page to generate the attachment list?
 
 > As for the attachment list, I envisaged that being optional. --Ben
 
 >> So some kind of preprocessor directive that is added to a page to generate the attachment list?
 

+>>> Absolutely. 
+

 I don't understand why the file size would need to be stored in the index file; this information is available by statting the file, surely? Similarly, the mime type can be determined through inspection, unless there turns out to be a reason to need to cache it for speed.
 
 I don't understand why the file size would need to be stored in the index file; this information is available by statting the file, surely? Similarly, the mime type can be determined through inspection, unless there turns out to be a reason to need to cache it for speed.
 

---[[Joey]]
\ No newline at end of file
+--[[Joey]]
+
+For images, videos, etc. it would be nice to have some kind of meta data file to go along with it
+(eg. image.jpg.meta), to store information like creator, title, description, tags, length, width,
+height, compression, etc. which could be initially created by 'ikiwiki --generate-meta-stuff'. 
+Then PageSpec should be
+teached to use these. Galleries could then be generated by means of
+\[[inline pages="type(image/*) and year(2007)" template="gallery"]].  It
+should of course be possible to edit this information via ikiwiki.cgi and with any
+text editor (Name: value). This should also allow for creations of default .html pages with
+the image/video/file/... and a discussion page. Probably named image.mdwn and image/discussion.
+ I think that would fit nicely with the ikiwiki concept. Comments? --enodev
+
+> Replying to myself. Just appending .meta gives problems when \$usedirs is enabled as the original file and the directory containing the html file will have the same name. Taking away the original extensions has problems with filenames having different extensions and the same basename. So something like 'about-image.jpg.meta'? That would require no changes to the core to support it and is reasonably easy to the eye.
+
+> I also pondered about putting this info in the rcs log, but that is problematic when you just 'cp'/'mv'/whatever the directory. Same goes for using something like svn properties, which git does not even support. Storing this info in the index file is problematic, because that isn't versioned. Major problem I see with this approach would be the disconnected nature of having two files. Posix extended attributes? ;-(
+
+> This could also be used to specify the license of the file.
+
+> I did an proof of concept implementation of this idea [here](http://ng.l4x.org/brainstorm/gallery/) yesterday night, including the link to the source code. I'd really love to hear comments about this approach.
+  (note1: I'm really not interested in any kind of http interface to that thing, just testing ways of storing the meta
+   data, note2: I'm no perl programmer)
\ No newline at end of file