I wasn't trying to imply that you shouldn't push to master, sorry if you got that feeling. It was more of an observation that part of the pull request had already been merged in.
Ah, I missed that you couldn't pass in function pointers. I think the encrypt is called in relatively few places (Encrypted Integrity Protected Data Packet/write_packet, Symmetrically encrypted Data Packet/write_packet), and the decrypt is similar as well (Encrypted Integrity Protected Data Packet/decrypt, Symmetrically encrypted data packet/decrypt_sym). There are a few other operations that directly call the CFB methods however... As far as packaging, yeah I was not thinking about the existing references to window.*, I think it would be kind of a hassle to have to import the various needed sections for web workers, so I like the idea of worker.min.js helper. Sean On Wed, Apr 11, 2012 at 3:27 AM, Tankred Hase <[email protected]> wrote: > > It looks like the initial changes were already pushed to master. > > Yeah those changes consisted of small code cleanup/modularization. I took > the liberty of committing this, as I figured this good for the library > either way. If we want to name the files differently than *.crypto.js and > *.crypto.sym.js, I am not religious about the names. > > > 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? > > Importing the whole min.js file wont work, since webworker will not like > all the document and window references. This is the reason I had to > modularize the symmetric encryption in the first place. What I actually do > in safewith.me is generate an additional openpgp.worker.min.js with just > the required modules for threading. > > Similarly, you're currently only using AES. > > Yes, this is just an example. Perhaps it would be possible to stick all > ciphers in a openpgp.worker.min.js file for the library, which would need > to be imported if multithreading is required. > > > I don't think adding one more file would be a huge detriment, but I'd > like to avoid it if reasonably possible. > > I agree, especially if it's optional. > > > 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? > > I would have suggested that one level higher as proposed in the example on > the pull request on github. This would require the asynchronous callback to > be "boubled up" to the public api, as you have correctly pointed out. > > The main problem is that you cant pass function pointers to a worker > thread (see pull request). > > Tankred > > _______________________________________________ > > http://openpgpjs.org > >
_______________________________________________ http://openpgpjs.org
