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
