A bridge with automated service discovery could be nice, but I fear that
it may also be too much bureaucracy and in the end may not help,
I would especially like to say, beware of the bureaucracy and anything
that looks like it. It has to do with what the values of pd are:
$1 = nice colours
$2 = nice layout
$3 = helppatches have consistent colours and layout
$4 = helppatches have consistent structure: every section that is supposed
to be in every helppatch has at least something written in it
$5 = helppatches are kept up to date
$6 = helppatches communicate concisely, minimising the boilerplate
copypasting that you have to learn to skip over in order to get to the
actual information
$7 = helppatches communicate the intent and the spirit of pd
$8 = helppatches are complete, communicating everything you may have to
know about pd
So far, PDDP emphasises the top of the list. If I were (or rather "when I
will be") taking care of documentation I'd concentrate on the bottom of
the list.
I especially don't care about PDDP because it emphasises $1,2,3,4. By
emphasising $1,2,3,4 it makes $5 that much more difficult and especially
it makes it boring. At least if you're writing tricky documentation and
you don't like writing documentation you can have a sense that you're
doing something tricky which uses your intelligence, whereas applying
$1,2,3,4 is not. Item $4 is especially infuriating because it puts the
respect of top-down rules of documentation more important than effective
communication, which may (and will) conflict with $5,$6,$7,$8, especially
if $4 doesn't doesn't include provisions for straying away from mere
form-filling.
To be fair, $7 is partially covered by the "all about" patches, but it
could be a lot more than that, especially considering $8.
I would continue with $9, $10, and more important values that are
completely foreign to PDDP, but this email is already long enough.
That help-patch may be quick and dirty, but it must *exist*.
That's very $8.
And a service discovery bridge may also be built later as a decorator
abstraction itself around the original abstractions.
You mean like http://en.wikipedia.org/wiki/Decorator_pattern ?
(original page at http://www.c2.com/cgi/wiki?DecoratorPattern )
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
