Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to email@example.com.
Eric, > Agreed, but you'll forgive me for saying so, but that seems like a very > closed-minded approach. One of the great sounding things about EVS is > that it seems to be incredibly flexible and allows for a lot of different > interaction between different types of applications. One of the ways that > I would see this as being open architecture would be to provide the > ability for other web applications (such as Bugzilla, Jira, Wikimedia, > Confluence, Fisheye, etc, etc, etc) to comunicate directly with EVS > instead of needing to parse log files, read the repository DB, etc.... Quite the opposite - we've written a C++ API that works terrific. As I wrote in my last post: > > I suppose in theory we could provide web api's for everything from the bug > tracker to browsing version to commit logs, but there is no plans to do > that in EVSr1 (Tony and I have got enough to do already). > Other people can of course create other API's. > It's a shame you didn't choose Java as the language of choice for EVS > given all the OSS libs and frameworks that could have helped make > development easier. (yes - I have become a Java convert over the last > years). Two of the requirements that excluded Java are: * high-performance * ease of deployment (no Apache or other 3rd party apps other than the DBMS) I suppose EVSMANAGER could have been written in Java, but we have no in-house expertise in that and specifically wanted to leverage existing expertise in C++ and it would have made deployment reliant on something like Apache. Regards, Arthur