> One of the ideas that James and I have been discussing, is an API for each > of the engines, allowing each engine to communicate with another Engine. > This API, in my opinion, would be absolutely best served with a local Web > Service gateway. Which would provide the obvious later growth into having > it as a public web service, allowing things such as the ferret_engine be > able to be searched on by remote or even local disseparate applications. > This is definitely the way I want to go as far as engines API are > concerned. It provides extreme flexibility when it comes to communication > of > functionality. > > For instance, if we create the Engine API using a standardized web service > architecture, future systems such as the authentication_engine would be > able to communicate with other Engines, such as the upcoming Toolbawks > Engine, or Ferret Engine (to make sure they have access to search that > content) with a very simplistic manner. I haven't yet got much experience > building Web Services, but I know enough high-level that this is the way to > go, we just need to make it happen. >
My instinctive response is that a webservice is NOT the right way to do this. A webservice would be useful for communicating between multiple machines/processes, or between multiple languages. We certainly do not have the latter, and while the multiple process/machines do exist, for the engines I'm aware of, there's no reason to not simply communicate in ruby using Ruby. Webservices just make it complicated. There might be value in an engine publishing it's API as webservice, but let's start with a Ruby API. David _______________________________________________ engine-users mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
