Alexei (on his new blog) announces EBA's first open source release.

Today we quietly open sourced EBA FTP Sync, a COM based file synchronization tool that more than a few people are using to perform tasks like automated backups. The neat thing about FTP Sync was always that we packaged it as a web tool… perform FTP synchronization from a web app.. neat idea.

We used it ourselves for years in our commercial CMS, which was a fairly elegant solution to the problem of migrating content efficiently between staging and production servers.

We’ve decided that the component would be of more use to people if it shipped with the source code.. we thought about lowering the price and then remembered that we’re an Ajax company and had no business selling ActiveX tools in the first place!

I met Andre Charland, head of eBusiness Apps about a year ago when I gave a talk at VanDEV about open source and your business. He teases us at Bryght about being a crazy open source company and I tease him about being Mr. Proprietary. It's great to see the team at EBA dipping their toes into the water of open source.

At Bryght, I’ve been working on an interesting project that really exercises the “toolkit” and “web services platform” like nature of Drupal. The final architecture of our project ended up having many distributed processes, all sending data to Drupal through XML-RPC, and we were using Drupal mainly to aggregate and display the results.

Performance was very important, and we were having a huge bottle neck with Drupal’s XML-RPC library. XML-RPC calls were talking a long fricken time, and we were making tons of them. Fortunately I had help from Walkah and Moshe, and I thought I would pass on what we did to drastically increase XML-RPC performance. This worked for us, so maybe it might help someone else out. The problem is of course that Drupal does a full bootstrap for every XML-RPC call.

Our solution: The first, simple (and huge) win was to utilize a PHP opcode cacher - this drastically reduces this bootstrapping time. We used eAccelerator, but there are many others.

Secondly, since we were working in a controlled environment (we knew what modules were going to be called via XML-RPC) we were able to hack the xmlrpc.php file to avoid a full bootstrap. The downside is we had to hardcode a few path things into the file, but again, this is for a particular app/site, and the performance gains were worth it.

At Bryght, I’ve been working on an interesting project that really exercises the “toolkit” and “web services platform” like nature of Drupal. The final architecture of our project ended up having many distributed processes, all sending data to Drupal through XML-RPC, and we were using Drupal mainly to aggregate and display the results.

Performance was very important, and we were having a huge bottle neck with Drupal’s XML-RPC library. XML-RPC calls were talking a long fricken time, and we were making tons of them. Fortunately I had help from Walkah and Moshe, and I thought I would pass on what we did to drastically increase XML-RPC performance. This worked for us, so maybe it might help someone else out. The problem is of course that Drupal does a full bootstrap for every XML-RPC call.

Our solution: The first, simple (and huge) win was to utilize a PHP opcode cacher - this drastically reduces this bootstrapping time. We used eAccelerator, but there are many others.

Secondly, since we were working in a controlled environment (we knew what modules were going to be called via XML-RPC) we were able to hack the xmlrpc.php file to avoid a full bootstrap. The downside is we had to hardcode a few path things into the file, but again, this is for a particular app/site, and the performance gains were worth it.