Hey guys, With the first release out the door (incidentally, did everybody already check out the download page?), it's time to start working on some new features. One important thing is that I'd like to more tightly integrate ACE into development environments so you can start using it right away (instead of it just being used in production). Actually, I've been discussing this a bit off list with Bram, and I'd like to summarize the ideas we have and invite everybody here to provide feedback.
Using ACE during development basically means we want to make the development cycle the same as the one used later during testing and production. That means we want to run a local ACE server and a target that basically gets updated every time you "save some change" and "build new bundles". How you do that obviously depends on the IDE and build tooling you use and there's lots of different ones out there. In the end they all produce one or more bundles though, and we'd like ACE to import those immediately and deploy them to the local target. We can already run an ACE server and target on localhost, so that's our starting point. The server could be launched independently of the IDE you use, the target we might want to launch inside the IDE to facilitate easy debugging and feedback inside the console of the IDE. As your build cycle will already produce an artifact on the local machine, we don't really need an OBR in this case. From within the ACE server we can directly point to a file URL. That saves us one extra copy step. So as soon as bundles have been built, we want to push them into ACE. For that we'd like to provide a REST client API that can either be used alongside the web UI or instead of it. Integrating different build and IDE systems based on a REST API is probably pretty straightforward, so that's why I think this is a good choice here. As soon as new or updated bundles have been added (and features and distributions defined) we can commit the changes and need to notify the target that there's something new to install. For that the server needs to send this notification (which for the general case might be troublesome since the server might not be able to reach the target, but in this case is no problem). The management agent on the target can then listen of these and poll for updates. It no longer needs to use the periodic scheduler, so we can disable that. WDYT? Any thing we're forgetting, can we be even smarter? ;) Greetings, Marcel
