8 Matching Annotations
  1. Jun 2020
    1. Disqus:

      As for publishing this as an actual gem on rubygems.org...I have enough open source I'm involved in all ready (or too much, as my wife would probably say) and I'm not really interested in maintaining another gem. Are you interested in taking over this code and releasing it as a gem and being maintainer?

  2. May 2020
    1. Despite our best efforts to deal with all of those issues, over the course of time we fall behind. When you look at an issue it's sometimes unclear whether or not we intent to provide the functionality you propose, whether or not we fix the bug, whether or not the issue is a duplicate of another one. In order to restore a reasonable level of clarity we annually perform a House Keeping Iteration in which we go through all open issues. We categorize, label, fix, and close issues. This results in a wave of notification which is hard to deal with (our apologies) but in the end there is better understanding of what will happen to your ideas.
    1. AppCache was standardized in the Offline Web applications section of the HTML specification. The standard is formally referred to as application caches. New Web applications should be built around Service Workers. Existing applications that use AppCache should migrate to Service Workers. AppCache access was removed from insecure origins in M70. This intent addresses AppCache usage in secure origins.

      First and foremost, AppCache is a deprecated standard with serious architectural concerns. Second, Chrome's AppCache implementation is a security and stability liability. AppCache is documented as deprecated and under removal in MDN and in the WHATWG standard, and marked as obsolete in W3C’s HTML 5.1. It is incompatible with CORS, making it unfriendly for usage with CDNs. Overall, AppCache was changed in over 400 Chromium CLs in 2018-2019. It has imposed a tax on all of Chrome’s significant architectural efforts: Mojofication, Onion Souping, and the Network Service. The security benefits of the removal are covered under Security Risks.

    1. Most traditional (monolithic) CMS systems are “coupled”, meaning that the content management application (CMA) and the content delivery application (CDA) come together in a single application, making back-end user tools, content editing and taxonomy, website design, and templates inseparable. Coupled systems are useful for blogs and basic websites as everything can be managed in one place. But this means that the CMS code is tightly connected to any custom code and templates, which means developers have to spend more time on installations, customizations, upgrades, hotfixes, etc. and they cannot easily move their code to another CMS.
  3. Apr 2020
  4. Mar 2020
    1. Yes, it’s been deprecated. Why? Because too few people were using it to make it worth the time, money, and energy to maintain. In truth, although I sometimes disagree with the operator changes, I happen to agree with this one. Maintaining ALL of the synonyms takes real time and costs us real money. Supporting this operator also increases the complexity of the code base. By dropping support for it we can free up a bunch of resources that can be used for other, more globally powerful changes.
  5. Dec 2019
  6. Aug 2019
    1. I second that and recommend the typings be moved to DefinitelyTyped. It’s an unreasonable burden for a library maintainer to manage them when they aren’t using TypeScript.