On 16/03/12 01:33, Tim Landscheidt wrote: > Magnus Manske wrote: >> [...] >> At the risk of over-designing, would it be worth to gather >> language-independent requirements for a module/library, on the >> toolserver wiki or on meta, and then keep implementations of that >> standard (yes, I know, "one more standard") available on the >> toolserver? At the very least, a language-neutral brainstorming might >> prevent design flaws, especially with database-with-API-fallback in >> mind. > > It depends on what you mean by "requirement". Something > like "a library *must* provide a function normalizeLink() > with these semantics" would probably deter developers from > trying to implement it. If on the other hand there was an > algorithm "if you want to normalize links, do A, B, C, D and > E" and corresponding test cases to check compliance, I think > it would be much more inviting. > > Tim
I think it really makes sense to define the names of a set of available functions. That would really make much simpler the development of portable tools, or working on different languages, without having to relearn the framework used. That said, each of us would probably push for their own API to be standarised. I don't think providing tests is the panacea for making people implement them. They are obviously nice, but as it would be open source, each user doesn't need to reimplement them according to the specification. The same code could be shared. The problem is in adoption of the API, and agreeing on an "standarised" one. _______________________________________________ Toolserver-l mailing list ([email protected]) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
