[pmwiki-users] Hiearchical Groups Proposal.

[Américo Albuquerque]

Joachim Durchholz wrote:
> Américo Albuquerque schrieb:
>> Joachim Durchholz wrote:
>>> Ideally, metadata would be pages, possibly with a special marker in 
>>> the page name so PmWiki knows that they don't get meta-metadata.
>>>
>> If metadata would be pages they could also have its own metadata. They 
>> wouldn't have metadata related to pages (like GroupAttributes, 
>> GroupHeader and/or GroupFooter)
> 
> You snipped the part where I explicitly wrote that metadata pages would 
> have to be marked so that they don't get metadata themselves.
> 
I know. I mean that those pages can have their own meta data. The only 
pages that wouldn't have metadata would be GroupAttributes, GroupHeader 
and/or GroupFooter
Other metadata that you could use (like the ZAP metadata) could also 
have their own metadata (like having their own ZAPAttributes)

>>> Downside is that if that's done to the final consequence and page 
>>> attributes (passwords) become separate pages, too, then PmWiki would 
>>> have to open an additional file to check view permissions. It would 
>>> also have to do a directory search since the metadata may be stored 
>>> several levels up the hierarchy.
>>> The wiki would have to have thousands of pages to make this a worry, 
>>> of course. *And* it would have to live in a file system that does 
>>> linear directory searches (i.e. it would have to be ext2fs, or ext3fs 
>>> with no -O dir_index.)
>>>
>> That would be bad, really bad. It would make pmwiki work just on linux. 
>> This mean that Windows and mac users would have to use older versions or 
>> change to other wiki engine
> 
> It's just the other way round: NTFS and HFS+ used indexed directories (I 
> just checked), so we have a non-issue on reasonably modern Windows and 
> Mac OS machines.
> 
> I could imagine that old Linux installations with an outdated file 
> system might have problems here.
> That's nothing that a backup - reformat - restore cycle couldn't fix, 
> though Linux administrators will usually loathe to have to do that. 
> Converting ext2 to ext3 with a dir_index option is even a low-risk 
> operation that can be reverted, and that may be possible with as little 
> work as dropping to a boot disk or rescue-system, adding a few options, 
> and rebooting the machine. (And if things don't work, there's always the 
> option to go back to ext2, so this is a low-risk operation.)
> 
Ah, ok. I misunderstood you there.

Américo Albuquerque