Thanks for the interest! I'll try to respond to everyone in this email. But first, who reading this would want to use an HTM over HTTP service like this? It means that you won't need to have HTM running on the same system that is generating the data. It's basically HTM in the Cloud. :)
On Sat, Dec 5, 2015 at 12:16 PM, Marcus Lewis <[email protected]> wrote: > I'm interested in HTTP GET, inspecting models. Great feature to add after a minimum viable product has been created, but this adds the complexity of either caching or persistence (depending on how much history you want). On Sat, Dec 5, 2015 at 2:03 PM, cogmission (David Ray) <[email protected]> wrote: > One thing I am concerned about is the call/answer nature of the interface > you describe because of the latency involved in a submit-one-row-per-call > methodology? Should it not be able to "batch" process rows of data instead? > (batches could contain one row if you were dedicated to being a masochist)? Yes, we will eventually need that, but I don't need it in the prototype. Let's focus on one row at a time and expand to batching later. > Next, at Cortical we use a technology called DropWizard which makes it very > easy to deploy an HTTP server capable of Restful queries (I have done this > for Twitter processing involving HTM.java). If this is going to use NuPIC and python, I have found that it's super easy to set up REST with web.py [1]. Just a matter for writing a class and a few functions. For REST on the JVM, I am open for suggestions. On Sat, Dec 5, 2015 at 5:50 PM, Pascal Weinberger <[email protected]> wrote: > Like a extended version of HTM engine? > This would be the solution to the htmengine prediction issue :) If we chose the HTM Engine option, then yes we would need to add some features to HTM Engine, especially prediction and user-defined model params. This is not a little job, but it would be great to have a scaling platform already built into the HTTP server. I would be happy even if we just started with an attempt to make HTM Engine (and the HTTP server in the skeleton app) deployable to a the cloud. Even with it's current capabilities, I could start using it immediately and we could add features over time. > Will you set up a repo in the community? :) Placeholder: https://github.com/nupic-community/htm-over-http Let's continue discussion on Gitter [2]. Our first decision is to decide which HTM implementation to use. I am leaning towards HTM Engine because it would take the smallest amount of effort to do the deployment configuration around it and get an MVP running the fastest (even if it doesn't to prediction or custom model params out of the box). IMO the best way to attack this is to get something minimal running ASAP and add features as required. [1] http://webpy.org/ [2] https://gitter.im/nupic-community/htm-over-http --------- Matt Taylor OS Community Flag-Bearer Numenta
