On 04/13/2013 09:24 AM, Chris Little wrote:
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.
I'm glad you did mention this, because I did bring this exact issue up
in JIRA a year ago. Please see:
http://www.crosswire.org/tracker/browse/API-153. So I did attempt to go
the appropriate channels. I started this discussion again at the present
time because I was advised by another Sword user to do so.
--Chris
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
