Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Feb 20, 2014
  1. removing contents of master as project has moved to Apache. Leaving R…

    Ken authored
    …EADME in place to point to Apache
Commits on Feb 14, 2013
  1. @brentlintner

    The section for what a build target is could use a better description.

    brentlintner authored
    Before, it seemed to not give full context to what a build target is,
  2. @brentlintner
Commits on Feb 7, 2013
  1. @brentlintner

    The `pkg/web` build target is no longer warranted.

    brentlintner authored
    This build target is no longer (primarily) used, and now that there is a
    hosted build target, which can function without the chrome extension
    (i.e. standalone) this is no longer needed, and should be removed.
    This also cleans up some hacky (complexity inducing) code (such as the
    omnibar checks) that has never felt right.
Commits on Feb 6, 2013
  1. @brentlintner

    Allow client to be injected and run in any (web) browser.

    brentlintner authored
    This means you can inject Ripple's client UI into any (hosted) app,
    provided you use the CLI's `emulate` cmd, so you need to:
    a) Be running locally with the npm package installed.
    b) Be running remotely with the npm package hosting your content.
    To emulate your app in a browser (ex: Safari), do something like this:
        cd ripple-repo
        jake && ./bin/ripple emulate --path to/your/app
    Then, open a web browser at the location logged to console, but with the
    `enableripple` query string param (as used in the Chrome Extension):
    This will inject the client UI in the same way the Chrome Extension
    Note: Currently, Ripple will attempt to inject itself on any .html file
          with a `<head>` tag in it.
    Note: This only works (at the moment) in select browsers (ex ones that
          have WebSQL). Browsers like FireFox is a TODO.
    Note: Updated the README to talk about using the hosted version, and
          removed the reference to the `pkg/web` target (which is no
          longer needed now that you can use the `pkg/hosted` target).
    Authored By:
        Brent Lintner <>
        Bryan Higgins <>
  2. @brentlintner

    The `npm` build target is unnecessary.

    brentlintner authored
    It felt consistent to have one when there was a `rim.npm` build target,
    but now that is no longer needed, you can install the npm package the
    usual way.
        npm install -g .
Commits on Dec 12, 2012
  1. @brentlintner

    Almond can be replaced with a more lightweight implementation.

    brentlintner authored
    Also, it is confusing (and more complex) to support both a `ripple`
    and a `require` method (for `lib/client` files), so the more
    lightweight implementation (of `require`) was renamed to (only)
    expose a method called `ripple`.
    i.e. If you are in `lib/client`, you _must_ use `ripple` (and
    Note: Since we use parts of Cordova (and not just with the addition of
    this piece of code), the LICENSE file was updated to mention this.
Commits on Nov 19, 2012
  1. @brentlintner

    If the npm package name is changed, everything breaks.

    brentlintner authored
    This commit is directly related to:
    The re-factor in the above commit was considered sufficient,
    however when the package name in `package.json` was changed
    to something other than `ripple`, the require pattern broke
    down, and nothing would really work, without making drastic
    changes to how node based JS was executed and packaged up
    (as an npm package), as well as testing said code.
    In consideration of that, it seemed most practical to change
    things to be less (for lack of a better word) fragile.
    There are two main changes this commit introduces.
    1. The way `require` is used has changed.
    For all node specific code, you require modules using relative
    paths (as usual, in node).
    This includes `lib/cli` and `lib/server`. See the HACKING file
    update for more details.
    For any code in `lib/client`, it is the same as before, except:
    You should use a global `ripple` method to require in a
    package relative to `ripple/client/..`.
    For example:
        var foo = ripple('foo');
    Would translate to
        var foo = require('ripple/client/foo');
    Ultimately, this gives absolute control on the method that
    "requires" modules, so when, say, you are testing the modules
    in a node environment, you can translate it to an absolute path
    that node will understand.
    The second change is that all core lib dirs are back in `lib`.
    This is because the main reason why code was moved out of `lib`
    was because of the way require was intended to be used across
    all (node/browser) environments, and now that it is not a
    necessity, having it in `lib` creates a more succinct top level
    directory structure, etc.
    Note: This also means the `npm link` step in `configure` is
    no longer needed.
    But, why have an inconsistent `require` paradigm across the project?
    Yes, indeed.. Well, the main reason is because this seemed the most
    practical, considering other alternatives, such as using relative
    paths in the large subset of (client) JS modules and packing it
    into a browser specific file that worked with relative paths, which
    is onerous (at best). And, because the code in the browser is
    ultimately different than other code in this project, and is
    sort of considered its own sub-project in many ways (i.e. perhaps it
    will become a separate project, but for now, this seemed best).
Commits on Nov 13, 2012
  1. @brentlintner

    Having static assets in the `server` folder is not consistent.

    brentlintner authored
    When the `server` component was created, a folder (`www`) was created in
    the directory (alongside the JS modules) for ease of implementation. It
    makes sense (in terms of consistency) to have those assets in the
    `assets` folder, just like the `client` component.
    Note: `assets/*` were moved into `assets/client`.
Commits on Nov 12, 2012
  1. @brentlintner

    There is (now) no need for the `rim.npm` package.

    brentlintner authored
    This is because we (as a company) will not need/have to deploy this
    project's NPM package to the registry, now that we are in the
    Apache Software Foundation incubator, which means there need not be an
    extra step (i.e. asking to accept a EULA).
Commits on Oct 29, 2012
  1. @brentlintner

    There should be documentation on the general architecture of Ripple.

    brentlintner authored
    Given it being a common convention, there is now a file in
    the root of the project (placed there for ease of discovery).
    There is also a reference to it near the top of the file.
Something went wrong with that request. Please try again.