How to design of a flexible file upload system for a wiki?

[19:00:11] <DarTar> the only thing I'm really jealous about is the way wacko handles file uploads (in terms of GUI)
[19:00:24] <DarTar> but that's not something the fork introduced, it was already there
[19:00:35] <DarTar>
[19:00:36] <brianko> actually, I'm sort of fond of the current uploader
[19:02:05] <DarTar> yes, but the idea that every page, automatically, can have uploads, without the need of adding a dedicated action, that's just brilliant IMO 
[19:02:16] <DarTar> it's the old action vs. handler discussion I guess
[19:02:41] <brianko> I like the idea that it's selective...pages *don't* have that capability by default
[19:02:47] <DarTar> hmm
[19:02:48] <brianko> drop the action where you need it
[19:03:16] <brianko> but I'm sure you could implement a file-based ACL system if that's what was needed
[19:03:27] <DarTar> I tend to think as file attachments as an essential part of a page
[19:03:31] <brianko> on a page-by-page basis
[19:03:31] <DarTar> just think of pictures
[19:03:44] <DarTar> yes files ACL are the next natural step
[19:03:50] <JavaWoman> how would that fit with our idea of treating files as resources, like pages?
[19:04:09] <DarTar> "that" what? 
[19:04:24] <JavaWoman> the wacko (fork) uploading method/UI
[19:04:50] <DarTar> it could still be possible to have files associated with permissions and ownership 
[19:04:55] <JavaWoman> and the "it' sautomatically there"
[19:05:18] <DarTar> but they would be thought as attachments to pages as opposed to files in a general purpose file manager
[19:05:45] <brianko> probably a system of links that connect pages and images
[19:05:48] <brianko> or files
[19:05:48] <DarTar> it's automatically there is merely a GUI issue
[19:05:52] <JavaWoman> ok, ut how do you control ownership and rights then?
[19:06:23] <DarTar> with dedicated file-based ACL 
[19:07:37] <DarTar> currently we have page owners, page write ACL, page read ACL
[19:07:44] <JavaWoman> I haven't thought this through, but there would need to be some control over the page-file connection (attachment) as well - or could anyone attach files to anyone's page?
[19:07:51] <DarTar> we would have file owners, file upload ACL, file download ACL
[19:08:12] <DarTar> I think page ACL would control file ACL
[19:08:14] <JavaWoman> yes, we'd need something like that
[19:08:30] <DarTar> someone, like the owner of the page, can decide that no one else can upload files to that page
[19:08:38] <JavaWoman> for instance
[19:09:06] <JavaWoman> so you have controls for separate resourcwes but also for  their connections/relationships
[19:09:12] <DarTar> or that some users can upload but everyone can download
[19:09:22] <DarTar> yes, it's a delicate thing to think through
[19:10:12] <DarTar> but I still think it's independent not dependent on the GUI issue (action vs. handler that is available for any page no matter what)
[19:10:20] <JavaWoman> indeed - it only just occurred to me really, when you mentioned the wacko "automatically there" fiel uploads
[19:10:56] <JavaWoman> no, you need the control system first, then just build a GUI for it
[19:11:18] * lcarsaway is now known as Lcarsdata
[19:11:56] <DarTar> if you want, but I still prefer to give someone the ability to upload files to any page (if he/she has the right to) without first having to add a {{files}} action to the page
[19:12:17] <DarTar> also because he/she may have no write access to the page, but still have file upload access to it
[19:12:24] <DarTar> right?
[19:12:26] <JavaWoman> then how woudl the page owner control it?
[19:12:42] <DarTar> it all depends on ACL set on the page
[19:12:50] <JavaWoman> there just needs to be *some* way - not necessarily {{files}} of course
[19:13:15] <JavaWoman> yes, an extension to the page ACLs could do it maybe
[19:13:36] <JavaWoman> it certainly shoudl not be dependent on page write access
[19:14:00] <DarTar> to me {{files}} as an action (= piece of code generating content) should mainly be used to call an attachment from within the page
[19:14:05] <JavaWoman> you shoudl be able to allow attachements to an otherwise locked down page, for instance
[19:14:10] <DarTar> exactly
[19:14:42] <JavaWoman> yes, {{files}} could still be used for its link-to-one-file capability
[19:14:59] <DarTar> the way I naturally think of this is as a /file handler much as a /info handler or a /pdf handler
[19:15:06] <DarTar> = do something with the page
[19:15:25] <DarTar> like, upload files to the page if you are allowed to
[19:15:27] <JavaWoman>  /attach ?
[19:15:39] <DarTar> yes, or /upload, whatever
[19:16:03] <DarTar>  /files is good because it's neutral
[19:16:19] <DarTar> could be for uploading/downloading, depending on ACL
[19:16:42] <JavaWoman> separate ACLs for upload and download, I think
[19:16:51] <DarTar> ok, so here's how I see this:
[19:17:11] <DarTar> - page level ACL determine who can upload and download by default
[19:17:27] <DarTar> - file level ACL determine who can do something with files once uploaded
[19:17:33] <JavaWoman> two ACLs -one upload, one downlaod
[19:17:54] <DarTar> sure, but you would have actually two ACLs at each level
[19:17:57] <JavaWoman> on page level
[19:18:04] <DarTar> both page level and file level
[19:18:10] <DarTar> right?
[19:18:26] <DarTar> actually three, there's also a delete ACL
[19:18:44] <JavaWoman> the file-level should be under the control of the file owner, like page level should be under the control of the page owner
[19:18:53] <DarTar> exactly
[19:19:29] <DarTar> so (1) page ACL would have upload/download/delete and would be controlled by page owner
[19:19:44] <DarTar> (2) file ACL would have download/delete and would be controlled by file owner
[19:19:44] <JavaWoman> with maybe automatic download rights for page owner if (s)he allows attachments in the first place
[19:20:37] <DarTar> I think a page owner should have something like admin rights towards files attached to his or her page
[19:20:57] <JavaWoman> (it woudl be a bit absurd to not have access to files you allow to be attached to your own page)
[19:21:00] <DarTar> so he/she can download them or delete them no matter what the file owner does
[19:21:07] <DarTar> precisely
[19:21:18] <JavaWoman> not delete - maybe "unattach"?
[19:21:33] <DarTar> hmm, what would be an unattached file?
[19:21:34] <JavaWoman> there shoudl be some way to access files independent from pages
[19:21:40] <JavaWoman> just a file
[19:21:45] <DarTar> ah, ok, that's the tricky part of the story
[19:21:47] <JavaWoman> a resource, like a page
[19:22:20] <JavaWoman> and an existing file could be attached to a new page, or an extra page  without having to upload it again
[19:22:28] <DarTar> IMO it makes more sense to still think of them as attachments to pages that can have their own life
[19:22:50] <JavaWoman> but it doesn't make sense that a page owner can delete someone else's property
[19:23:00] <DarTar> hmm
[19:23:34] <DarTar> this means that there should be an actual, page-independent file manager in the wiki
[19:23:38] <JavaWoman> IMO you have to start from thinking of files as independent resorces - then look at how they can interact with pages
[19:24:06] <JavaWoman> yes - manage your own files (or files you have control over, for admins)
[19:24:30] <JavaWoman> that file manager should also make it possible to attach a file to  a page that allows this
[19:24:41] <DarTar> this is user-oriented, whereas my idea was much more wiki-oriented
[19:24:51] <DarTar> quite different visions
[19:25:08] <JavaWoman> yes - I've always thought of files as resources though
[19:25:45] <DarTar> I think-as a 3rd way-that files can still be thought as resources even if they are bound to pages in terms of access
[19:26:33] <DarTar> so you could link to, say: SandBox/files:picture.png from page MyPage via the {{files}} action
[19:26:33] <JavaWoman> what if the page owner no longer allows files to be attached?
[19:26:53] <JavaWoman> IMO you *cannot* allow a page owner to cause files to be deleted that belong to someoe else
[19:27:01] <DarTar> as I said, this the natural consequence of the page owner's being considered as an admin on attached files
[19:27:30] <DarTar> then in my view this someone else should upload files to a page he/she owns
[19:27:42] <DarTar> and allow others to link to these uploads
[19:27:42] <JavaWoman> that woudl have severe consequences for ownership
[19:27:50] <DarTar> possibly
[19:27:54] <brianko> JavaWoman: If it's my page, and I permit uploads, I should be able to do with them what I want (in terms of deletion)
[19:27:54] <JavaWoman> intellectual rights and all
[19:28:06] <JavaWoman> brianko, I don't agree
[19:28:08] <brianko> Just as if I hosted an FTP server
[19:28:20] <DarTar> huh, I haven't even thought of intellectual property...
[19:28:31] <brianko> If I decide to delete my page, then the file will no longer be accessible anyway
[19:28:40] <brianko> Do I give the file back? :)
[19:28:43] <JavaWoman> you are not allowed to delete somenoe else's pages - why shoudl you ne allowed to delete someone else's files?
[19:29:06] <DarTar> if you delete a page, all comments from other users go, right?
[19:29:11] <JavaWoman> no, if the file is a resourece on its own it just becomes unattached - but still owned by its owner
[19:29:43] <DarTar> so your rights on the comments are subordinate to the right of the page owner
[19:29:44] <brianko> hmm...that doesn't make sense.  A wiki shouldn't be a file repository
[19:29:49] <JavaWoman> conceptually, a comment has a different relationship with a page (it's *about* a page) than an attached file
[19:30:01] <DarTar> ok, that's precisely the point where we diverge :)
[19:30:04] <brianko> If the ref count for a file goes to zero, it shold be deleted
[19:30:12] <brianko> Why would you keep it around?
[19:30:19] <JavaWoman> why shoudln't it be a file repository? look at how wikipedia handles images
[19:30:25] <DarTar> I use to think of files as being about a page in a wiki environment
[19:30:33] <JavaWoman> they are quite independent frmo pages where they are linked
[19:30:42] * DarTar doesn't like the central repository idea of MediaWiki
[19:30:57] <brianko> Because there are better applications for maintaining file repos
[19:31:03] <DarTar> zakly
[19:31:07] * JavaWoman does like it because it respects intellectual rights
[19:31:43] <DarTar> rights are saved as long as you upload your files to pages you own
[19:31:53] <DarTar> and allow others to link to them
[19:32:14] <JavaWoman> right- allowing links shoudl be yet another ACL
[19:32:15] <DarTar> it's really two very different views about page/file relations
[19:32:51] <DarTar> well, in my idea described above allowing links would be the same as download ACL
[19:32:51] <JavaWoman> if I attach an image to *my* page that doesn't necessarily imply that otehs can use that  image in *their* pages
[19:33:04] <DarTar> ok good point
[19:33:14] <DarTar> although in a wiki...
[19:33:27] <JavaWoman> linking is different from downloading
[19:34:02] <DarTar> I thought linking as the result from file owner's download ACL on the file + page owner's write ACL
[19:34:13] <DarTar> on the target page
[19:34:34] <JavaWoman> but maybe there coudl be a way to link to an image that automatically credits the owner - image link action?
[19:34:35] <DarTar> so if a file is downloadable and I have write access to a given page, I can link to that
[19:35:10] <DarTar> my feeling is that the IR layer should totally be distinguished by the resource ownership layer
[19:35:13] <JavaWoman> no, downloadintg means grabbing it and putting it on your own computer - that's fundamentally different from linking to it
[19:35:49] <DarTar> because IR are established via immaterial clauses, regardless of what the infrastructure allow you to do *if you happen to get in possession of a resource*
[19:36:33] <DarTar> well, I could also copy the content of the page of another user on my page and claim the content is copyrighted by myself
[19:37:02] <JavaWoman> claim != truth - it'd be a violation
[19:37:36] <JavaWoman> unless the owner of course explicitly allows this
[19:37:37] <DarTar> exactly, but a violation establised by the rights the original author puts on the content, not on the material possibilities to reproduce/reuse that content, right?
[19:37:48] <JavaWoman> rihgt
[19:38:11] <DarTar> which boils down to my suggestion of separating the IR layer and the resource management layer, IMO
[19:38:36] <JavaWoman> yes, good point
[19:38:41] <DarTar> :)
[19:38:49] <JavaWoman> and it makes it even more complicated
[19:38:52] <DarTar> lol
[19:39:04] <DarTar> here's another handler we need: /license
[19:39:11] <JavaWoman> time for back-of-the head adn let it simmer a bit ;)
[19:39:31] <DarTar> with a default wiki-level license that can be overridden by page owner and can be overridden by file owners :))
[19:39:52] <JavaWoman> sigh - something like that, yes ;)
[19:39:56] <DarTar> lol
[19:40:07] <JavaWoman> with defauls configurable, of course
[19:40:26] <DarTar> a wiki with flexible rights managements sounds like a cool idea
[19:40:38] * JavaWoman is getting a headache and still need to do that page tweak and application letter...
[19:41:01] <DarTar> ok, this is for Wikka 9.0 anyway

There are no comments on this page.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki