> I played around with OMP a few days now (and implemented a Python OMP > client library). From my point of view, OMP is inconsistent and not well > designed. I know, there is already quite some software around using OMP > as it is now. So use it this comment as "lessons learned".
As Jan said, we plan to look through OMP for consistency issues before the release. > Here are some examples: > > * Each request defined it's own response element (eg. create-task, > create-task-response). Perhaps there are reasons for that, but > this makes the (server) source more complicated and error frown. The reason is that it makes it easy to match the response in a stylesheet. > * When creating or deleting e.g. Targets, the name is specified as > element, but when searching, an attribute has to be used. Yes. Deleting will be changed to be by UUID when the Targets get UUIDs, so it will be more consistent then. > * The get_* and delete_* commands are quite redundant: they only differ > in the tag name and whether a id attribute or a name tag has to be > used. Something like this would simplify the code: > <delete type="note" name="Some Note" /> > <get type="note" name="Some Note" /> The complexity is still basically there, because the delete and get handlers would have to check the type and act accordingly. It's also conceptually simpler to just have separate commands. > * Using "task_id", "report_id", etc. instead id a common "id" does not > add functionality but make the code more compilcated. Sometimes more than one type of ID is specified in a single command. > * For escalators, the method element is extremely ugly, mixing text > content and child elements: > > <method>Email<data><name>to_address</name>[email protected]</data> > > This would better we something like > <method type="Email"> > end perhaps > <data name="to_address">[email protected]</data> Maybe true, but then we lose the option to extend type and name with more info in other entities. > Just my 2 cent Thanks for it. As Felix said, please feel free to contribute your Python code. -- Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner _______________________________________________ Openvas-discuss mailing list [email protected] http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
