[pmwiki-users] Attachment handling enhancement request

[Patrick R. Michaud]

On Wed, Mar 28, 2007 at 03:00:56PM +0200, ThomasP wrote:
> My items were meant as rhetoric questions: whatever the situation is now I
> just wanted to expose what should be taken into account if one makes
> changes or amendments.

Okay, excellent.

> For example, regarding reference to arbitrary files I would say it is at
> least not very intuitive at the moment if -- given per-group based storage
> -- one wants to address a file in another group than MyGroup, and has to
> write the markup
>     Attach:MyOtherGroup.AnyPage/myfile.txt
> in the page MyGroup.SomePage. 

Actually, an author can write

    Attach:MyOtherGroup./myfile.txt

and the '.' makes it clear we're referring to a group instead of a page.

> (If I'm right this is also the source of the problem that Dominique
> encountered when he wrote:
>
> > in the related group configuration pages. But, I'm now stuck with the
> > fact that there isn't any way to refer to attachments from one group
> > into another.
>
> [...] )

No, Dominique's issue is that he wants a site where some groups have
the attachments organized per-group, while other groups have the
attachments organized per-page.  Since he's changing the storage model
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.)

> 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