> On Jul 10, 2017, at 18:03, Kenneth Chan <kenn...@apache.org> 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 Eventserver. I do not foresake this design goal, but ask that we consider the usability & durability of PredictionIO when deploying multiple engines with different versions of PIO and different storage configurations. This will probably happen for anyone who uses PredictionIO long-term in production, as their new projects come on-line with newer & better versions & configurations. I encounter this situation of 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 configs. Also, those in the consulting world are frequently required to keep client data separated for all kinds of privacy & legal reasons; with the storage corruption bug I reported, one client's data could become visible to or intermingled with another client's app. In starting this thread, I was hoping to find some traction with the idea of making it possible to completely self-contain a PredictionIO app by adding the Events API to the process started with `pio deploy`. Goal: Queries & Events APIs in the same process. When considering the architecture of apps, sharing a database between two or more apps is considered a very naughty way to get around having clear, clean, inter-process API's. My team at Salesforce/Heroku has been struck by this exact issue with PredictionIO. So, I am seeking a way to fix this without requiring a rewrite of PredictionIO. I am excited to hear about the new architecture prototypes, yet our reality is that this is an issue now. *Mars ( <> .. <> )
