Patrick, agreed to every point. If I understand you right then "attached to" reads like "associated with", and files that happen to be stored on let's say per-group basis are associated with every page of that group [1]. (Ergo the file can be downloaded via any of these pages, ergo read access to at least one of the pages in the group is enough to download the files.)
The "Nowadays" paragraph is quite, say, "interesting" ;-) This little fact must have slipped through my daily "Pmwiki reading list". Concerning > from one group to the next, PmWiki is unable to use the model from > the current group to find the attachments in a group with a different > model. (In other words, it's unrelated to the markup syntax.) > : This problem would consequently not occur when using a storage oriented way of referencing, since the targetting of the file would be done in the markup, not in the "resolver" variable $UploadPrefixFmt (which could be group dependent as in Dominique's case to reflect different storage types). Thus, half joke, half serious: if anyone is ever interested I propose a markup "File:..." which is targetting files exactly as stated in the markup, e.g. an absolute "File:/MyGroup/MyPage/blah.txt", or a relative "File:blah.txt" targetting file blah.txt in the page (or group (*)) dir corresponding to where the markup is placed. Instead of "File:" also "Disk:" may be appropriate to emphasize the storage orientation. Thomas [1] Pm: "For per-group or sitewide organizations, it's simply the case that the attachments appear to be available to multiple pages" (*) depending on UploadPrefixFmt setting > >> Somehow I think it would be better if the referencing would _reflect_ >> the >> way of storage (per-group or per-page based), which would be much more >> understandable to users instead of explaining them why the reference >> must >> have the current special form "group.page/file.ext". > > Nowadays we simply say that to refer to another group one uses "group." > (with > the dot). This is true whether referring to an attachment or to the > home page of another group: > > Attach:Group./xyz.txt > [[Group. | go to Group's home page]] > >> Somehow I think it would be better if the referencing would _reflect_ >> the >> way of storage (per-group or per-page based), which would be much more >> understandable to users instead of explaining them why the reference >> must >> have the current special form "group.page/file.ext". > > I'm going to take the position that the very name "attachment" (which > was deliberately chosen) implies that we're associating files with > individual pages. If we change the referencing to reflect the underlying > storage model, then let's not call them "attachments". > > In fact, there's absolutely nothing that prevents us (well, recipe > writers) > from providing other access models or referencing models -- just use > a different prefix than "Attach:". The two can coexist quite nicely. > >> Besides there should be a clear and intutive default search path >> whenever >> the file reference is not fully qualified, i.e. Attach:file.txt. > > At the moment Attach:file.txt always refers to whatever file.txt is > attached to the current page. That seems to be pretty clear. > >> ... if I remember right I saw the >> permission check being done based on the page where the Attach: markup >> was >> _located_, not based on where the _file_ was located. I can be wrong >> with >> this, but if it is like this, it is also a security issue ... > > No, the permission check is based on the page(s) to which the file is > attached. That's unrelated to where the Attach: markup is located, > or where the file is located. > > Pm > _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
