Thanks Julius, but our DLL does all of the following, as well as compiling on our build server to work in our mobile app, in Docker Containers, and in Microsoft Azure -  it's more effective to retain complex business rules in a .NET library so that it can be used on a much wider basis. Also, .NET is easier to maintain in the sense that adding any new barcode format to the DLL updates all of our environments, not just the Cache one. We're into microservices in a big way, Cache is just our facade pattern entrypoint to the whole distributed system. Alot of the business rules tranlation is done simply by exchanging JSON at the microservice REST endpoints (we've also got a QR code Server in a docker container that's standalone and accessible by anything via a REST endpoint), however somtimes it's easier just to slap in a DLL as per the above question. Also, a lot of our team's expertise is tied up in .NET technologies so quite often a .NET solution is quicker and easier than passing the technology transfer information to the Cache developers. Thanks though.

Aztec 2D barcode format.

CODABAR 1D format.

Code 128 1D format.

Code 39 1D format.

Code 93 1D format.

Data Matrix 2D barcode format.

EAN-13 1D format.

EAN-8 1D format.

ITF (Interleaved Two of Five) 1D format.

MaxiCode 2D barcode format.

PDF417 format.

QR Code 2D barcode format.

RSS 14

RSS EXPANDED

UPC-A 1D format.

UPC-E 1D format.

UPC/EAN extension format.

I agree with the idea of migrating the back-end code to some other technology - I've broadly costed this and it would likely cost more than a quarter of a million pounds, there is so much there.

My ideal situation (other than not using Cache for the data store and using something open-source) would be to merely use Cache as a REST based data store that would essentially be an interaction of JSON requests and responses, and, as you say, do the front end otherwise. In fact I'd go so far as to make it facade pattern so that any client technology (mobile, ASP.NET, node.js, etc) could interact with it as required.

You're right about it being blazing fast - but I can't even find a use case for that, from the Mobile user's point of view there is little noticable difference between getting a response from Cache on a rack somewhere, and, for example, various SQL databases from an Azure or AWS cloud.

I'm sure our National Health Service and such departments as the Police Force have great use cases for this technology but I'm still scratching my head to figure out how it is useful to a small web app where the only real user is the REST endpoint that actually queries Cache.

Thanks for your comments!

Thanks! With 1/4 million people coming through our client's gates for their festival over a mere week, forcing logout is important. We have done tests and without logout, actual user licences being used are artificially high, and it means that we'd be paying higher licence fees than are actually being used.

However you spiked an interesting case, I haven't tested how the server times out the sessions that haven't been logged out and doing so should reduce the number of faux-licence stats.

Thanks!

Eduard, sorry, but you miss-read my comment, I marked 'my' answer as accepted, as my explanation of my fix was in my comment 'to' Stefan.

And just to iterate that answer here, I put the pages concerned through an HTML validator and we discovered some tags that were no longer legal (frameset), even though some browsers still accept this in quirks mode, Android (Xamarin) doesn't.

Hi Stefan, thanks!

I've just resolved the issue, we used http://validator.w3.org/ to validate the HTML and as it turns out the Android webview is really strict and breaks when validation errors occur.

In our case it was a Frameset tag, which although not being legal, are still currently rendered in the other browsers that we use.

So guess what, I'm context-switching from my usual Xamarin duties where I consume the Cache generated content, to figuring out how to style an iframe instead, to work on all browsers. Tricky, because the iframe has to expand to the viewport, and then the content link has to zoom to the bounds of the iframe so that no scroll bars are shown.

Thanks for your suggestion!