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