Re: Eventserver API in an Engine?

And glad you did. The needs of Heroku are just as important as any user of an Apache project *but no more so* since one extremely important measure of TLP eligibility is to demonstrate freedom from corporate dominance. So let me chime in with my own reasons to look at a major refactoring of

Re: Eventserver API in an Engine?

I'm bringing this thread back to life! There is another thread here this week: *How to training and deploy on different machine?* In it, Pat replies: You will have to spread the pio “workflow” out over a permanent > deploy+eventserver machine. I usually call this a combo PredictionServer > and

Re: Eventserver API in an Engine?

Mars, i totally understand and agree we should make developer successful. but Would like to understand your problem more before jump into conclusion first, a complete PIO setup has following: 1. PIO framework layer 2. PIO administration (e.g. PIO app) 3. PIO event server 4. one or more PIO

Re: Eventserver API in an Engine?

The prototype has multiple engines of any type, that can accept any events that they understand. There is no such “illusion” afaict. If there are a set of templates that accept the same events this works just fine. As I said “they may even share validation code” and the new input method can be

Re: Eventserver API in an Engine?

re: " when deploying multiple engines with different versions of PIO and different storage configurations needing separate PIO installs regularly when testing the next release or development builds of PIO and when evaluating engine templates or algorithms that require new, different storage

Re: Eventserver API in an Engine?

One of my biggest work pieces is scaling of deployments including all services to fit the data. Then once this is accomplished changing that as data changes or fine tuning to reduce costs. upgrading has not be difficult for the PIO part but certainly is when upgrading storage backends or heaven

Re: Eventserver API in an Engine?

> On Jul 11, 2017, at 09:18, Pat Ferrel wrote: > > But this is demonstrably untrue. Try it. Clustering for some templates > assumes textual data, others do not. This seems so far from my experience > that your statement is baffling. The PIO event stream from one

Re: Eventserver API in an Engine?

> On Jul 10, 2017, at 18:03, Kenneth Chan wrote: > > it's all same set of events collected for my application and i can create > multiple engine to use these data for different purpose. Clear to me, ⬆️ this is the prevailing reasoning behind the "separateness" of the

Re: Eventserver API in an Engine?

it's all same set of events collected for my application and i can create multiple engine to use these data for different purpose.

Re: Eventserver API in an Engine?

"I understand what you are aiming for—namely data independence from model and engine—but it is impossible and seems a very odd place to abstract when you put it in real terms. A Recommender will never need the same data as a neural net, a clusterer, or a classifier. This abstraction does not exist

Re: Eventserver API in an Engine?

I must disagree here, The Engine should decide the disposition of data, which cannot be left to a generic EventServer. Data is the concern of the Engine, not the EventSever or PIO framework for these reasons: 1) input needs to be validated and since it is defined by the Engine it seems rather

Re: Eventserver API in an Engine?

Mostly agree with this. but if we want to do Kappa-style online learners they do not need dataset storage but do need realtime input. On Jul 8, 2017, at 12:31 AM, Kenneth Chan wrote: # re: " I see it as objects you see it as data stores" not really. I see things based on

Re: Eventserver API in an Engine?

re: "bundling event server as engine" depending on how we wanna separate the concern. the way i look at it is decouple 1, data collection service (PIO event server) and 2. modeling and prediction service (PIO engine) - that's the separation of concern. Ideally data is agnostic to engine, and

Re: Eventserver API in an Engine?

Actually I think it’s a great solution. The question about different storage config (https://issues.apache.org/jira/browse/PIO-96 ) is because Elasticsearch performs the last step of the algorithm, it is not just a store for models, so it’s an

Re: Eventserver API in an Engine?

Are you asking about the EventServer or PredictionServer? The EventServer is multi-tenant with access keys, not really pure REST. We (ActionML) did a hack for a client to The PredictionServer to allow Actors to respond on the same port for several engine queries. We used REST addressing for

Re: Eventserver API in an Engine?

Hey Mars, Thanks for the suggestion and I agree with your point on the metadata part. Essentially I think the app and channel concept should be instead logically grouped together with event, not metadata. I think in some advanced use cases, event storage should not even be a hard requirement as

Eventserver API in an Engine?

One of the ongoing challenges we face with PredictionIO is the separation of Engine & Eventserver APIs. This separation leads to several problems: 1. Deploying a complete PredictionIO app requires multiple processes, each with its own network listener 2. Eventserver & Engine must be configured