- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Fri, 11 Oct 2013 11:28:26 +0100
- To: Matteo Collina <matteo.collina@gmail.com>
- Cc: public-rdfjs@w3.org
>> (Perhaps there's some cases where a better API design can allow for better performance, I would consider that functionality, not performance.) > > Agreed. That’s not correct: performance is a non-functional constraint. See my original mail: once libraries decide on the functionality they will support, they choose non-functional constraints, and this influences the design. Performance has little to do with API design—it depends on internal design decisions. Two libraries can have the same API but vastly different performance or other characteristics. >> I don't think performance matters even the least in our initial comparison. Performance can always improve; the feature set, functionality, compatibility, and security is much more important. No, it cannot always improve. There are limits for any non-functional constraint and they are inherent to the design; that was the whole purpose of my mail. This is exactly why I argue that we need such non-functional aspects in a comparison. If four APIs are evaluated against a spec, you can’t say that “A passes it more than B”. You say: A passes the spec, B does not; A is faster than C for in-memory but D is asynchronous. This, together with the feature set, allows for meaningful comparison. One goal is to help people decide which library to use; there’s more than functionality or we wouldn’t have this many libraries. Best, Ruben
Received on Friday, 11 October 2013 10:29:06 UTC