Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor file structure #16

Closed
TheBlueMatt opened this issue May 12, 2014 · 6 comments
Closed

Refactor file structure #16

TheBlueMatt opened this issue May 12, 2014 · 6 comments
Milestone

Comments

@TheBlueMatt
Copy link
Contributor

We have like...two, and it needs to be clearly cut and defined, with nice API lines between

@TheBlueMatt
Copy link
Contributor Author

Random notes on this:

I like js/crypto.js, js/webcrypto.js, and js/api.js. I'm currently thinking rename js/helpers.js to like js/textsecure.js and then move those into a textsecure-lib folder or so. Those will then be publicly consumable and can form the backbone to any JS-based TS plugin.

@TheBlueMatt TheBlueMatt added this to the 0.1 milestone May 16, 2014
@TheBlueMatt TheBlueMatt self-assigned this May 16, 2014
@liliakai
Copy link
Contributor

helpers.js is the file of shame--nothing personal, just kindof a big lump
of spaghetti code. renaming it won't make it prettier. I suggest a strategy
of parceling off logical chunks until there is no more helpers.js.

If you make a textsecure.js (or perhaps it should be signal.js or
whisper.js or even axolotl.js), it should probably just define the main
library interface, with functions for sending messages, and registering
onMessageReceived (or similar) event callbacks.

On Thu, May 15, 2014 at 8:11 PM, Matt Corallo notifications@github.comwrote:

Random notes on this:

I like js/crypto.js, js/webcrypto.js, and js/api.js. I'm currently
thinking rename js/helpers.js to like js/textsecure.js and then move those
into a textsecure-lib folder or so. Those will then be publicly consumable
and can form the backbone to any JS-based TS plugin.


Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-43291486
.

@TheBlueMatt
Copy link
Contributor Author

Oh, no question it's a huge mess. My point is more to reactor it into modules that actually make sense together and then hide most of the crud from public api consumption.

@TheBlueMatt
Copy link
Contributor Author

Took out some of the low-hanging fruit in 05101b6 and 6bc19ef. Mostly just split out things into semi-logical namespaces. The real offenders are still there (and not namespaced) but the namespaced things are somewhat clean or, at least, clean enough for a release to me.

@TheBlueMatt
Copy link
Contributor Author

Well, +/- some really ugly APIs which need cleaned (promises so we can expose exceptions and error handling, mostly)

@TheBlueMatt
Copy link
Contributor Author

Closing this, as it is out of date and in progress, at least for most of the issues (feel free to reopen with more specifics if anyone disagrees).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants