[tahoe-dev] help! how do I manage dependencies on JavaScript code?

[Paul Hummer]

On Thu, 2 Sep 2010 22:37:27 -0600
"Zooko O'Whielacronx" <zooko at zooko.com> wrote:

> I actually agree with Kevin that visualization is very important. But,
> I've realized that was a mistake to be try to squeeze a big new
> feature in at this stage of the 1.8 process. We had to commit some
> significant changes to download logic after 1.8.0c2 because that was
> the only way to fix a performance regression, but now we're going to
> concentrate on fixing known bugs and hunting for unknown bugs until
> 1.8.0 final.
> 
> As soon as 1.8.0 final is out we will turn to the very cool patches
> waiting to be merged into trunk: Brian's New Visualizer (which is the
> topic of this thread), Kevan's MDMF (GSoC), Faruq's multi-introducer
> (GSoC), *maybe* some of Yu Xue's advanced cryptography (GSoC) (if Yu
> Xue or someone writes some more code to integrate it into Tahoe-LAFS
> capabilities).
> 
> We have a half-baked idea of how to solve the JavaScript dependencies
> problem by making the visualizer code be a Secure Decentralized Cloud
> App. :-) Commit Brian's patches to Tahoe-LAFS which cause it to emit
> its download status report in JSON, but don't commit any of the actual
> JS visualization code nor jQuery nor protovis to Tahoe-LAFS. Then
> upload jQuery, protovis, and the visualizer code into the grid itself
> and link to it so that the user sees it whenever they look at the
> status page. Something like that. :-)

That's kind of crazy, but it might work for me.  I was actually thinking
that, as a packager for Ubuntu, I'd make an entirely different package
for the stat code, with its own dependencies, etc.  If you expose it as
a webservice (with JSON or something), the stats app can be entirely
different, and so can be opted into.

-- 
Paul Hummer
http://www.paulhummer.org

"Government exists to protect us from each other. Where government has
gone beyond its limits is in deciding to protect us from ourselves."
-Ronald Reagan