FEATURE FREEZE?

[rhyolight]

@breznak @jefffohl I think this project is very cool, and I'm glad you are working on it. I'm ready to use it if it in more than one project, including River View.

But, at this point I think you should focus on getting this codebase ready for production and stop all work on new features until it is actually deployed and being used in a few places. We are going to find bugs and new issues as we attempt to deploy this charting tech, and it s better to find out any big issues now before any further architecture changes are made that might somehow affect deployment strategies. (I am talking about issues like #42, #43 & #48.)

What do you guys think?

[jefffohl]

Sure. If it is getting a lot of interest, then I suppose we should do releases. We can target issues to planned releases.

Speaking of deployment - if modularization is a big priority - that is, make it so that any number of nupic.visualizations can be dropped on a page with a minimum of configuration - then we should make that a priority issue. It isn't really designed that way right now. Right now, it is designed to be an entire stand-alone application, as opposed to being a part of some other app.

[rhyolight]

Yes, and I much prefer it to be a drop-in charting tool. I think it can be
both if we treat this repo as a client-side drop-in charting tool and add
another server repo that makes is stand-alone.

---

Matt Taylor
OS Community Flag-Bearer
Numenta

On Fri, Dec 11, 2015 at 8:41 AM, Jeff Fohl [email protected] wrote:

Sure. If it is getting a lot of interest, then I suppose we should do
releases. We can target issues to planned releases.

Speaking of deployment - if modularization is a big priority - that is,
make it so that any number of nupic.visualizations can be dropped on a page
with a minimum of configuration - then we should make that a priority
issue. It isn't really designed that way right now. Right now, it is
designed to be an entire stand-alone application, as opposed to being a
part of some other app.

—
Reply to this email directly or view it on GitHub
#49 (comment)
.

[breznak]

To me the feature freeze is a bit confusing - depends what you want to use this for. For me, for example, the code is OK enough for a 1.0. #40 is not a high prio for me, I'd like to see support for the streaming functionality #17 and anomalies ( #3 #31 )

[jefffohl]

Since @rhyolight needs streaming as well, perhaps we should make that the highest priority?

[rhyolight]

My concern when creating this issue was simply that too much up-front engineering would be done before we had the charting system actually being used somewhere. I think I had the wrong impression that the end goal was a drop-in JavaScript library that could be used for live-streaming temporal data.

If you guys are willing to do the work now to ensure I can use this charting system in my own web applications, I would be happy. Otherwise, I'll continue to use Dygraphs directly.

[jefffohl]

I want to make it something you can use Matt. We just need to define the interface.

[breznak]

@rhyolight what's the missing parts for you? The #40 and #17 ?

[jefffohl]

I think we also need to know what to leave out. What would be the responsibility of the charting module, and what would be the responsibility of the parent app? What UI elements do we include, etc.

[rhyolight]

All I need right now is #40. Streaming can be done later.

[jefffohl]

Can we chat on Gitter? I need more detail.

[rhyolight]

I think the UI component would be this:

[breznak]

I would add the file selection to the UI, actually the existing app minus the header...
Make it into a "namespace secure" div and the app can be easily dropped anywhere, have multiple occurrences at a page, etc.
I'd hope to add more controls to the UI in a near future, but it'll be in the div, thus transparent update to any apps using it