I did in fact mean using Uint8Array. I've merged the changes for major/minor versioning back into the project, I think this will help us identify what version of the code people are using. I know that I have run into trouble with this in my extension, and I don't think it's practical for us to continue manipulate a minor version number for small changes.
On a more exciting note, I also did some work with running our code against jsdoc https://github.com/jsdoc3/jsdoc and have added that into the "doc" directory. Essentially, it generates Javadoc-style webpages based on our JS code. We will need to do some work to clean up a lot of our comments, but I think this provides us with a framework to provide more usable documentation. Sean On Mon, Aug 20, 2012 at 4:43 AM, Tankred Hase <[email protected]> wrote: > Hi, > > The roadmap looks good. > > Ive recently tested firefox nightly. Window.crypto.getRandomValues() isnt > merged yet. > > What do you mean by "better file handling" in chrome? Do you mean handling > of binary data with Uint8Array typed arrays? > > Tankred > Am 19.08.2012 01:28 schrieb "Sean Colyer" <[email protected]>: > >> I agree that this is the most important thing in keeping the project >> moving forward. I added a Roadmap page to the wiki >> https://github.com/openpgpjs/openpgpjs/wiki/Roadmap I'd like others to >> take a look/comment/edit. >> >> I'd like to avoid this becoming a duplicate of our issues page but have a >> handful of large things that we can tackle. >> >> In my opinion, I think top priority things will be to >> >> - Documentation >> - Flush out existing issues dealing with some more packets/clients >> that we don't currently >> - Firefox support >> >> I think some of the other things like significant refactoring will be a >> stepping stone to things like UTF-8 better file support. >> >> Thoughts? >> >> Sean >> >> On Mon, Jul 30, 2012 at 9:48 PM, Jim Klo <[email protected]> wrote: >> >>> Sean, >>> >>> As far as delineating major versions, I'll leave that to you to >>> wrestle with the core team. But I'd say, If there's no need to break things >>> up right now into major versions, don't. Leaving yourself a way out to >>> manage branches in the future is what I'm proposing. Using a single value >>> just makes that tough and creates strange race conditions if you don't >>> figure it out early. >>> >>> My 2ยข? I think you're mostly targeting support for Chrome in 0.1, you >>> might want to add support for both Chrome/Firefox, that seems to be a >>> logical place for a more major revision, say a 0.2. That way if there's >>> some set of users that are using 0.1.x branches, but you found that to >>> support FF in 0.2.x that forces a major api change, you can safely make >>> that change and not effect 0.1.x users. You can choose to stop support for >>> some old branch, but you're agreeing not to change the underlying API to >>> 0.1.x. But say some security flaw is found in code that effects both 0.1.x >>> and 0.2.x, you'd want to patch both, but not force all users to upgrade to >>> 0.2.x. >>> >>> So take the versioning approach more as a mechanism for defining a >>> roadmap. You've started some of that here graphically: >>> http://openpgpjs.github.com/ >>> >>> Maybe: >>> Define v 1.0 as where you want a full set of features to be for JS and >>> Chrome, until you get there it's a 0.x.x version, bug fixes and maint. >>> would be 1.x.x. >>> Define v 2.x, 3.x as supporting more engines/formats as you want. You >>> can always revise the future goal before you start. >>> >>> All this will make you think about what are the full compliment of >>> features you need for each version, which is a good thing. Also if you >>> define the roadmap of things to get done, on an open source project, you're >>> likely to get more contributors to step up and say, I need that feature, so >>> I build it and contribute it back. It also allows someone from the >>> community to start building the future out before you start... say someone >>> need's IE support, but it's not slated to start until v 4.x... that can >>> live in that branch for an indeterminate amount of time until you decide to >>> actually deal with it, but you have the code somewhere where it doesn't >>> effect current versions in production. >>> >>> * >>> Jim Klo >>> Senior Software Engineer >>> Center for Software Engineering >>> SRI International >>> * >>> * >>> t. @nsomnac >>> * >>> >>> On Jul 30, 2012, at 6:19 PM, Sean Colyer wrote: >>> >>> I stupidly was not paying attention during part of my changes and was in >>> a detached HEAD state and merged the pull request back in. Once I realized >>> this, I reverted master back to the change it was at. >>> >>> I've opened a new pull request that people can look at >>> https://github.com/openpgpjs/openpgpjs/pull/50 that includes the >>> additional commit I was originally just going to fold into master that is a >>> bugfix for: https://github.com/seancolyer/gmail-crypt/issues/12 >>> >>> Jim -- I think that's a reasonable approach. Do we have any >>> suggestions on how we might delineate what are deemed to be major versions? >>> So far we've pretty much dodged versioning all together. >>> >>> Sean >>> >>> On Mon, Jul 30, 2012 at 9:00 PM, Jim Klo <[email protected]> wrote: >>> >>>> The problem introduced however is that you cannot delineate between >>>> versions between significant changes in design.. say you have to patch all >>>> released versions with security fix (say you have a 0.1, 0.2, and 0.3)... >>>> by using only a datestamp you don't know which architectural fork the code >>>> base belongs from version number alone. >>>> >>>> I might suggest following a pattern that Node, Python, and several >>>> others follow where you use: major.minor.rev where OpenPGP.js >>>> v0.1.20120730 >>>> >>>> This way you can have several versioned 'forks' and can easily >>>> distinguish, ie: v0.2.20120730 from v0.1.20120730 >>>> >>>> - Jim >>>> >>>> * >>>> Jim Klo >>>> Senior Software Engineer >>>> Center for Software Engineering >>>> SRI International >>>> * >>>> * >>>> t. @nsomnac >>>> * >>>> >>>> On Jul 30, 2012, at 5:17 PM, Sean Colyer wrote: >>>> >>>> I've made a pull request to change the way we do versioning for our >>>> builds. Basically replacing the hardcoded "OpenPGP.js v0.1" with a date >>>> like "OpenPGP.js 20120730". >>>> >>>> I'm interested to see if others think this is a good idea, the >>>> project has changed hugely since the original "0.1" and I think it makes a >>>> lot more sense for us to have the version reflect which version of code is >>>> actually running. However, please let me know if this doesn't seem like a >>>> good approach? >>>> >>>> https://github.com/openpgpjs/openpgpjs/pull/49 >>>> >>>> Sean >>>> _______________________________________________ >>>> >>>> http://openpgpjs.org >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> http://openpgpjs.org >>>> >>>> >>> _______________________________________________ >>> >>> http://openpgpjs.org >>> >>> >>> >>> _______________________________________________ >>> >>> http://openpgpjs.org >>> >>> >> >> _______________________________________________ >> >> http://openpgpjs.org >> >> > _______________________________________________ > > http://openpgpjs.org > >
_______________________________________________ http://openpgpjs.org
