Why you should stay clear of REST. Part II

Pro Documentum

Actually, as a continuation of previous blogpost I wanted to write about DDD and my own experience with DFS, CMIS and REST, but today I have found another gem on LinkedIn: Performance Anti-Pattern For RESTful API – batch updating (saved copy), actually that blogpost hides package names:

but all we do know what is hidden there:

As far as I know, batch updates were introduced in 7.2 and they are dead slow 🙂

Another LinkedIn gem: Potential Permanent Generation Leakage In Your JVM

View original post

PDF.js

Technology Services Group recently published a blogpost which compares PDF.js and OpenAnnotate, unfortunately, all their comparison is based on hypothesis that PDF.js does not support progressive loading:

PDF.js loads the entire PDF into the client via JavaScript. This works fine for moderately large documents (10 pages), however many of our clients have documents in the 300-700 page range. Larger files put a lot of strain on the network, and leaves minimal options when it comes to performance tuning.

Which is actually not true, because PDF.js does support progressive loading since 2013: Implement progressive loading of PDFs, actually, it is more correct to say that PDF.js does support progressive loading since birth, because PDF.js was originally created as a Firefox extension and was included in Mozilla Firefox since 2012 (version 15), and it was enabled by default since 2013 (version 19). Unfortunately, after receiving a couple of valuable comments Technology Services Group embarrassingly decided to remove those comments and close blogpost for further comments:

Those valuable comments were:

  • PDF.js does support PDF annotating capabilities via plugin
  • If TSG thinks that progressive loading does require linearized PDFs, why they do not optimize all PDFs before storing

The most interesting thing here is a fact, that progressive loading does not require linearized PDFs: