web commit by http://madduck.net/

[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 02eaf569352e3739203b551bdbf896c05e54d728..1ce52f0ca128922d54b247420548895da8012424 100644 (file)
--- a/doc/todo/fileupload/soc-proposal/discussion.mdwn
+++ b/doc/todo/fileupload/soc-proposal/discussion.mdwn
@@ -1,8 +1,8 @@
-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.
+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|ikiwiki/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.

 
 > Thanks for clarifying; I clearly misunderstood the original text. -- Ben
 
 
 > 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.
+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|ikiwiki/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? 
 
 
 > 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? 
 


@@ -39,4 +39,8 @@ the image/video/file/... and a discussion page. Probably named image.mdwn and im
 
 > 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? ;-(
 
 
 > 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.
\ No newline at end of file
+> 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)