Hi, maybe this will give some inspiration for the OpenPGP.js high level api. This is our crypto library (not OpenPGP compatible). But it provides a high level Api that is worker/multithreading compatible, since it does the symmetric session keygen (window.crypto.getRandomValues) before starting the encryption. This can't happen in the web worker due to the invocation of 'window'.
https://github.com/whiteout-io/crypto-lib#example-code All Apis are async with the format "callback(error, returnValue)". This way web worker logic can be put behind it or not. Does this help? Tankred 2013/10/24 Thomas Oberndörfer <[email protected]>: > My point on the AMD vs Browserify topic is is: > > We are currently redesigning the high level API in the devel branch. > Like in the current version of OpenPGP.js it's a synchronous API. > Now Tankred mentions web workers, and there is also the project > from Peter on Web Crypto (that I just have started looking at). > The former requires asynchronous interfaces and the latter as far as > I understand is based on promises. > > A future proof high-level API in the devel branch would be flexible enough > to incorporate all these different requirements. The question is how to evolve > the current interfaces in this direction. I'm thinking of a setup where we > have > different configurations for build targets (like standard, web worker, > web crypto) > and can replace single modules in the configuration but at all time test > against > all targets. > > Does that make sense and can this be achieved with AMD? > > Thomas > > > On Thu, Oct 24, 2013 at 8:55 AM, Tankred Hase <[email protected]> wrote: >> One other thing comes to mind if we wanted to put standard >> encrypt/decrpyt operation in a web worker e.g. If an app wanted to do >> bulk processing of emails off the main thread (which would block for >> seconds). >> >> You can't do that in a worker with browserify because openpgp.js needs >> to collect encrypt using window.crypto.getRandomValues. Generating >> keys outside a a worker thread is very possible with AMD since you >> don't have to bundle and can load single modules selectively. >> >> Tankred >> >>> Am 24.10.2013 um 08:34 schrieb Tankred Hase <[email protected]>: >>> >>> Hi, >>> >>>> Am 24.10.2013 um 04:06 schrieb Sean Colyer <[email protected]>: >>>> >>>> I'm not sure I see huge advantages for OpenPGP.js using AMD/require.js. It >>>> seems a bit cumbersome when I've looked at writing it. I think >>>> common.js/browserify approach is more common, and seems an easier path to >>>> node support. The build step seems pretty minor to me but I am curious >>>> about why AMD has been much better for testing in your experience. >>> >>> You can mock dependencies for unit tests using the require.js config. >>> The build step can also become cumbersome during testing. >>> >>>> I'm not totally opposed to it, but I'm just not entirely convinced that >>>> it's worth switching right now. Do you think it would increase our >>>> longterm ability to develop OpenPGP.js? >>> >>> Thomas also had some some concerns. I don't want to intrude the >>> current refactoring. I think want you guys are doing is great. >>> >>> The main advantage I see is community support and stability. >>> Require.js is much more battle proven und is used by projects such as >>> jquery. >>> >>> We've also had some big problems getting the browserified bundle to >>> work with web worker as you would have to load the whole bundle and a >>> single invocation of window or document in the bundle would make it >>> impossible. This is why forge goes the AMD route. That way they can >>> load JSBN.js for generating keys in two parallel web worker threads >>> that don't block the ui. If we want to reuse these things, it would >>> probably be easier with AMD. >>> >>> Regarding the long term EcmaScript 6 will introduce a standard module >>> system, that is different from both AMD/Commons.js anyway so it >>> wouldn't make mich difference. >>> >>> http://www.2ality.com/2013/07/es6-modules.html?m=1 >>> >>> All in all I can understand if you guys want to stick with common.js. >>> >>> I'm curious how you currently invoke the minified bundle in the >>> browser. I had to add the following line to the index.js to make it >>> work >>> >>> if (typeof window !== 'undefined') { >>> window.openpgp = module.exports; >>> } >>> >>> Tankred >> _______________________________________________ >> >> http://openpgpjs.org >> Subscribe/unsubscribe: http://list.openpgpjs.org > _______________________________________________ > > http://openpgpjs.org > Subscribe/unsubscribe: http://list.openpgpjs.org _______________________________________________ http://openpgpjs.org Subscribe/unsubscribe: http://list.openpgpjs.org
