improve message

[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 05d2ddddeb5eefc1f85f96c84c34a60a3af42118..b2c06f378ec4f3a3363bd2fe15d9fbea24ed94a8 100644 (file)
--- a/doc/todo/fileupload/soc-proposal/discussion.mdwn
+++ b/doc/todo/fileupload/soc-proposal/discussion.mdwn
@@ -1,6 +1,24 @@
-There's nothing in [[fileupload]] that suggests putting the file upload limit in the body of a page. That would indeed be a strange choice. Ikiwiki already uses [[PageSpecs]] in the Preferences page (for specifying locked pages, banned users, and subscriptions), and I had envisioned putting the file upload controls there, and possibly subsuming some of those other controls into them.
+There's nothing in [[fileupload]] that suggests putting the file upload limit in the body of a page. That would indeed be a strange choice. Ikiwiki already uses [[PageSpecs|PageSpec]] in the Preferences page (for specifying locked pages, banned users, and subscriptions), and I had envisioned putting the file upload controls there, and possibly subsuming some of those other controls into them.

 
 

-It's not clear to me that the concept of attaching files to a page fits ikiwiki very well; unlike most wikis, ikiwiki supports subdirectories and [[SubPages]], which allows for hierarchical placement of uploaded files, which is a much more flexible concept than simple attachment. Futhermore, the idea of listing all attached files at the bottom of a page seems somewhat inflexible. What if I want to make a podcast, using inline's existing support for that -- I won't want a list of every "attached" file at the bottom of my podcast's page then.
+> Thanks for clarifying; I clearly misunderstood the original text. -- Ben
+
+It's not clear to me that the concept of attaching files to a page fits ikiwiki very well; unlike most wikis, ikiwiki supports subdirectories and [[SubPages|SubPage]], which allows for hierarchical placement of uploaded files, which is a much more flexible concept than simple attachment. Futhermore, the idea of listing all attached files at the bottom of a page seems somewhat inflexible. What if I want to make a podcast, using inline's existing support for that -- I won't want a list of every "attached" file at the bottom of my podcast's page then.
+
+> If a file was attached to _some-dir/some-page_, it would be stored in _some-dir/_ and linked from _some-page_. That would seem reasonably hierarchical to me. What do you suggest as an alternative? 
+
+>> 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?
+
+>>> 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.