Oh yeah! We're using biometric data to understand the emotions people are feeling. My job is to analyze the data to determine what emotions like fear, elation, stress, and tension look like. I'd love to use Jut for that
Indeed — @davidbcook as i mentioned before please feel free to point your developers here. We’re eager to enable users at this point (and to help find the problems that people will run into with the new world of juttle).
The first question is what led you to think that? As to the actual answer it’s a bit nuanced — it’s true that in the new world, we no longer have juttle components involved with the ingest pipeline so we don’t have a tap into the incoming “live” data like we used to. However the plan is that for adapters like elasticsearch, we would still support combined historical + live queries but would implement it with a “pseudo-live” mode where the read command would first do the historical part, then query every N seconds for new arrivals.
Now - when accessing something like orchestrate with the http adapter, my thought is that you would need to tell the read command something about how the API to which you’re communicating handles time filters (which we don’t yet have). At that point you could map the -from and -to arguments to corresponding API requests, and then the support for combined historical and live would come for free
Now that’s not something we have yet but would be pretty easy to add on and has been in my head as something we should do.
So I'm running outrigger and juttle locally for now, and I just had some trouble running a simple program. I had 2 syntax errors, but outrigger didn't tell me I had any syntax issues, it just gave me a black screen with the run button and this in the console: Failed to load resource: the server responded with a status of 400 (Bad Request) (you're probably aware of this but just thought I should bring it up)