[pmwiki-users] Hiearchical Groups Proposal.
aalbuquerque at lanowar.sytes.net
Wed Oct 18 14:40:09 CDT 2006
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
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.
More information about the pmwiki-users