On 4/12/2013 3:31 AM, Peter von Kaehne wrote:
Having said this, I think if there is a large number of existing modules which get insufficiently rendered and if the patch required is small, then I would suggest a two pronged approach: 1) accept the patch (us) 2) Do not accept anymore modules requiring this patch (IBT) 3) Once the last module requiring it is gone in IBT we can "unpatch" again. I think this is a sensible compromise between integrity of the engine and the needs for existing modules to present correctly. Quite unlike many other "hacks" we have seen in modules this is a well documented, XML compliant, logical hack not exploiting any existing faults in a frontend or the engine. Peter
I would say that this is something that we absolutely should not do. It's bad practice and sets a bad precedent.
For stability reasons we should not ever be adding features with an expectation of later removing them. We cannot predict when users will upgrade or even whether they will upgrade. So, effectively, we can't ever identify when it is safe to unpatch.
More importantly, I have a real problem with how this proposal is coming to us. If you have a problem and a concrete solution, the appropriate next step would be to propose it to sword-devel and get some feedback. It doesn't matter how good, how minimal, how innocuous, or how clever you believe your solution is, you should get some feedback.
If you choose instead to implement your solution without consultation and to release content employing it, you don't get to turn around and demand compliance to your ad hoc solution. In the event you actually have come up with a good solution, it might get added to the library, but it would depend on the merits of the solution itself--not your choice to release content requiring it.
--Chris _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
