Re: Image_Magick_Conjure

> In principle, putting it in pear seems perfectly sensible. Ok, so I'll make the requested changes. > You should go through the 'package proposal system' I thought the first step was to discuss about the package on the mailing-list. > - please have a read through the Coding standards, > * phpdoc comments Only the main file containing the main class is Pear-coding-standard conformant for the moment: http://grincheux.codelutin.org/~monnier/php/conjure/MSL_Parser.html http://grincheux.codelutin.org/~monnier/php/conjure/api/ I have started the correction of the sub-files: http://grincheux.codelutin.org/~monnier/php/conjure/Releases/php-conjure0.01-e.tgz Not perfect yet, but though there are still tabs here :p http://pear.php.net/go-pear that should be sed'ed :)) > * case xxx: action;action;break; - should be on seperate lines.. For the very long constant switches, it makes it hardly less readable. But if it absolutely have to, I will reformate those, in which case using constant() would perhaps be preferable. > * method names studly caps Even for private ones? Notice that all are private, since the interface is XML. The only one user should call is : $msl_parser = new MSL_Parser; $msl_parser->Parse($msl_content); > * eventually plan to break it up into 1file/class.. (if we ever get > there with that RFC..) Ok I can plan it adding this in the todo list, but I won't be able to do this work in only one week, like the other changes/corrections. > I'm not presonally sure on the wisdom of creating a scripting language > in XML.. Ok so don't consider it as a scripting language but as a file format :) The .xcf (native Gimp) can't be consider both as a scripting language and a file format, because all layers are hardly as .o! All layers are compiled, I mean it is impossible to know what are the filters that have been used (and of course neither the parameters of those applyed filters). I will try not troll to much about Gimp here :) but notice that with .msl file format, it is possible to really provide an image under a Free licence, which one would then be really 100% modificable since all layers are here not precompiled. So a black and white SVG logo + MSL effects is perfect to provide GNU licenced logos. > it's a pretty messy format for data transfer, gives me > nightmares for programming :) In graphics, XML file format is quite common now, here are some infography apps which currently use XML for their file format: (.scd .svg .kpm .x3d) - Scribus - Sodipodi - KPovModeler - Image-Magick (.svg, and work in progress for .msl) The work is in progress for Blender for a native XML file format. > it's a pretty messy format for data transfer, gives me > nightmares for programming :) --- troll: content: Would you prefer a yaml formating for MSL? :) link: http://yaml.org comment: Should be possible to switch the formating from/to yaml/xml. ... (troll (content "Or an SXML formated why not? ;-)") (link "http://okmij.org/ftp/Scheme/SXML-short-paper.html") ) More seriously, how would you prefer scripting deeply nested structures such as layers one? Do you think you could imagine an api as clear and simple than this, and that can also be a file format at the same time? http://grincheux.codelutin.org/~monnier/php/conjure/incantation.html Would this really give you nightmares? -- Cheers