Sounds like a good app Matt, I can help out. Personally, for getting an web app off the ground quickly in python I recommend pyramid: http://www.pylonsproject.org/
On 7 December 2015 at 03:31, Matthew Taylor <[email protected]> wrote: > 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 > > -- *Jonathan Mackenzie* BEng (Software) Hons PhD Candidate, Flinders University
