ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Integrating ACE into your development environment...
Date Fri, 10 Jun 2011 14:42:59 GMT
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


Mime
View raw message