Shayan's error stuff
6 views
Skip to first unread message
Caitlin Potter
Nov 21, 2012, 1:43:43 PM11/21/12
to osdw...@googlegroups.com
Okay so, here's my thing:
I wrote the initial code that we're working with, however I am not (and would not claim to be) the "boss" of the project that can decide hands down on features to include or not include
The summary of my argument is this: Users have the power to use their own dynamic list of errors, if that's what they want to do. However it's not something that the library should implement for itself. The reason for this is because A) It's not really "needed" by the library itself, it's more of a convenience (or inconvenience, depending on the needs of the application). B) It's a big chunk of delicate code that we will have to maintain and test regularly.
Even if you ignore point A), point B) is a big one, in my opinion. The library is flexible enough to let users log errors any way they like, so there's no "good" reason to do it in the library. Beyond that, it's an area that is quite likely to introduce bugs and break with subsequent changes to the API or parser. So because of this, I think it is ill-advised to add this code _to the library_
I wrote the initial code that we're working with, however I am not (and would not claim to be) the "boss" of the project that can decide hands down on features to include or not include
I've left comments on Shayan's pull request, which seem to be ignored, so maybe I'm not really communicating the issues very well.
The summary of my argument is this: Users have the power to use their own dynamic list of errors, if that's what they want to do. However it's not something that the library should implement for itself. The reason for this is because A) It's not really "needed" by the library itself, it's more of a convenience (or inconvenience, depending on the needs of the application). B) It's a big chunk of delicate code that we will have to maintain and test regularly.
Even if you ignore point A), point B) is a big one, in my opinion. The library is flexible enough to let users log errors any way they like, so there's no "good" reason to do it in the library. Beyond that, it's an area that is quite likely to introduce bugs and break with subsequent changes to the API or parser. So because of this, I think it is ill-advised to add this code _to the library_
That said, I am not opposed to adding it to the parsevtt sample application (and I created an example of this at https://github.com/caitp/webvtt/tree/error-stuff)
However, since I am not the "boss" of the project, I think that we should come to some degree of consensus on what people think makes the most sense.
It really needs to be decided on as a group before we are able to close/cancel the pull request (https://github.com/humphd/webvtt/pull/53)
However, since I am not the "boss" of the project, I think that we should come to some degree of consensus on what people think makes the most sense.
It really needs to be decided on as a group before we are able to close/cancel the pull request (https://github.com/humphd/webvtt/pull/53)
Reply all
Reply to author
Forward
0 new messages