Alan Knowles wrote:
> 1. the navigation of snippets needs to take into account that there is limited
> space on the interface. - hence long names are a bit difficult to see,
> especially if the relivant information is at the right hand side. (and as an
> opinion, this navigation space should always be limited against the
> 'editing/viewing area' of an interface.)
OK, that's a good point.
> 2. the user looking at the top level snippet dir, should in theory be able to
> see what snippets they have installed very quickly.
You mean a flattened view of the snippet space?
> these lead us to the 'short prefix' and having a wide base tree rather than a
> shallow one with snippets inside.
>
> if we did adopt a domain based 'naming convention', then it would involve a
> number of issues:
> changing all the code (not really a major concern)
> having very long mgd_include_snippet lines - not very nice...
> extra complexity with limited advantages when using and looking at snippetdir
> trees. - even if we hid the complexity, that would introduce confusion when
> writing mgd_include_statements....
>
> looking at other conventions for this type of thing....
> package naming - redhat & debian = has very little structure (eg only -dev)
> etc.
> package storage -
> - redhat = none
> - debian = /web/XXXXXX (function based top level directory)
>
> perl modules - installed
> - /usr/lib/perl5/
> MIME, Mail, Apache, CGI, Weblint ....
> perl modules - on server
> /id/NAME/Files
> all other indexing uses symbolic links (and textfile indexes)
The thing that must be taken into account is that with RedHat, there's a
single known
entity controlling the namespace -- RedHat. For Perl there's CPAN which
gives swift
insight if 'your' namespace entry has been taken...
> The middle letter would have to be 'registered' centrally if it was to be
> distributed (eg. with midgard).. however users are left to their own devices
> when creating their own snippets, the suggestion being that the create their
> own 'ID' and if any id's clash, then a simple ereg_replace on the code could
> fix that.....
... which means we'd have to be that CPAN in this case. I think the idea
is OK,
but frankly, I'd need someone to be the CMAN-master.
Emile
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
