[pmwiki-users] Attachment handling enhancement request

ThomasP pmwikidev at sigproc.de
Wed Mar 28 12:11:57 CDT 2007


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
>





More information about the pmwiki-users mailing list