Roadmap

[brianjmiller]

1.0.0

• Switch default for allowFail in LRS
• Drop synchronous request support (see default to async? #108)
  • Switch to LRSResponse return objects
  • Add promises interface
• Drop IE6, IE7, IE8?, IE9? support
• Drop 0.9 support
• Drop 0.95 support
• Switch to a get/set model for properties to allow for validation, etc.
• Modernize dependencies:
  • CryptoJS -> forge?
  • xhr2 -> ? (isolate HTTP handling to defined interface to allow multiple implementations)
  • jshint -> eslint
  • qunit? -> at least update to 2.x+
  • check all others
• Switch to not include build artifacts in repo

[hyperTwitch]

If you plan upon dropping IE8 and/or IE9 support is there going to be some way to back fill this for those who still need to support those browsers?

[brianjmiller]

I wouldn't anticipate that being a problem given the nature of JS. At this point I don't have any plans to restrict IE8/9, but I also wouldn't want to limit the capability of the library's interface for them, nor do we really want to continue spending the majority of the tiny amount of time devoted to the library on supporting them. I would also expect that we could create a branch for the 0.x series that could be patched by others, but it wouldn't get the kind of review and testing that the mainline branch gets.

[hyperTwitch]

That is understandable, and so long as it is possible to support that functionality through a separate branch or additional plugin or some other manner I don't see this being an issue for the projects I oversee. So long as we have access to unminified and non-obfuscated versions of the code it shouldn't be too hard to debug anything which may come up that you guys may be unable to handle within the time you have available for the library.

[nudoru]

I favor dropping those older browsers and adding support for newer standard. I wrote a wrapper on top of this that added ES6 promise support for my own use. Maybe that's the best way to support new standards.

[zpetterd]

While it isn't widely available, would using the beacon API were available be considered https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon ?

Simply it allows you to more or less queue a request which will be sent by the browser even if the browser tab is closed. So you could send/update a statement on unload without impacting the user experience.

[brianjmiller]

@zapur1 given sendBeacon is still very experimental as far as support is concerned I'd say it is too early to give a black/white response of support or no support. I don't expect it will be added anytime soon, not without significant browser adoption.

Having said that, I'm not quite sure what the library would use it for. In general the concept of when a statement is sent has been left entirely up to the users of the library and I'd expect us to continue with that approach. Trying to get all the various conditions of when to send, how much to send at once, what to do on failure to send, where to locally cache, etc. lead to lots of decisions that are generally just better left up to the developer and their application. Assuming sendBeacon supports a complex enough request (I didn't quite get that feel from the doc but am happy to be wrong) then you could use the serialization of a TinCan.Statement to handle getting the data, etc. and go ahead and use it now.