It looks like the initial changes were already pushed to master. As far as the webworker -- I like the progress.
I notice in the web worker you're importing individual subcomponent js files (i.e. util.js), this will not work well in environments that only plan on deploying the entire openpgp.js (or min) file. Is it too bad overkill to point it to openpgp.js? Similarly, you're currently only using AES. Which brings me to my next thought about how to deploy the webworker/do we want multiple files. I think it is not ideal to have to distribute multiple files, but I'm not sure there is currently a better way. I see there is the inline BLOB strategy, but that doesn't seem clean. Any thoughts on a way to make sure the project stays easily deployable? I don't think adding one more file would be a huge detriment, but I'd like to avoid it if reasonably possible. In regards to where to integrate it, I haven't had a chance to completely think this out but I think the hard part is that it needs to basically bubble it's way back to the root calls. I think it is most advantageous to provide the callbacks at the root level API, unless I'm missing something. I'm thinking you might be able to inject the callback into the existing openpgp_crypto_symmetricEncrypt by adding an additional parameter which is the optional callback. If it is set, initialize a worker thread that will call the same openpgp_crypto_symmetricEncrypt(/Decrypt) as you have the workers laid out currently, and without the callback option they will run as it exists now. Is that similar to what you were thinking? Thanks, Sean On Fri, Apr 6, 2012 at 7:44 PM, Tankred Hase <[email protected]> wrote: > I have thought a bit more about how to integrate WebWorker/Multithreading > support gracefully into OpenPGP.js. Here's my suggestion: > > > 1. We create a "wrapper" for the web worker code in > 'src/ciphers/openpgp.crypto.worker.js' > 2. This file gets a dependeny to the synchronous symmetric entryption > logic currently in 'src/ciphers/openpgp.crypto.sym.js' (see webworker > branch). > 3. We add an additional (optional) asynchronous callback to the place > that usually invokes 'openpgp_crypto_symmetricEncrypt' and > 'openpgp_crypto_symmetricDecrypt'. In that place, we check for WebWorker > support and 'if(window.Worker)' we > invoke 'src/ciphers/openpgp.crypto.worker.js' else we invoke the symmetric > crypto in 'src/ciphers/openpgp.crypto.sym.js' as usual. Only that the > values will be returned through the "asynchronous" callback rather than > through return. If the optional callback is not defined by the caller, we > return the synchronous/blocking symmetric crypto as usual. > > This approach would not break the current public API of openpgp.js, but > rather add optional multithreading support. I think it would be better to > do it this way than refactor the API for only asynchronous style, since > it's easier to get started using the librara if it's synchronous by > default. Also most applications such as simple email encryption will not > require multithreading. > > Carsten, Sean... I am currently not familiar enough with the code to know > where 3. should take place. Any thoughts? > > Tankred > > > Am 7. April 2012 07:23 schrieb Tankred Hase <[email protected]>: > > Here's a link to the changes on Github: >> https://github.com/openpgpjs/openpgpjs/pull/39 >> >> Oh, and Happy Easter from the bunny, btw :) >> >> Tankred >> >> Am 6. April 2012 23:12 schrieb Tankred Hase <[email protected]>: >> >> Hi, >>> >>> I've got openpgp.js' symmetric encryption working in a seperate web >>> worker thread. If anyone is interest, here's the code: >>> >>> >>> https://github.com/tanx/SafeWith.me/blob/webworker/war/js/safewithme.crypto.js#L336 >>> >>> This required some minor refactoring/modularization to openpgp.js and I >>> created a pull request on Github. Feedback is welcome. >>> >>> Tankred >>> >> >> > > _______________________________________________ > > http://openpgpjs.org > >
_______________________________________________ http://openpgpjs.org
