...
Alexandre: any idea of decoupling the architecture? Maybe using a queue service that would allow the logic, presentation and data layers to be in different servers, for example to make better use of server infrastructure such as might be available through Amazon?
Jim -- starting with 1.5 we added the RDF service to unify how the application accesses data, and paves the way for working with other triple stores, as Weill Cornell, Florida, and others are doing
The search engine can also be swapped out
Jim -- now common to put a triple store on a different machine (whether through Jena’s SDB triple store using MySQL or another triple store) -- this is fairly common
Solr could be moved to another machine, as Duke has done -- they have two front end instances of VIVO web/Tomcat so it makes sense to share 1 SolrH instance -- Paul thinks Weill-Cornell may also be running Solr on a separate host than VIVO web app
Hoping to reach the level of decoupling the reasoner to another platform by VIVO 1.9 -- and allowing some levels of the reasoning to be done inside VIVO and some outside
Stefan -- does VIVO use Spring (the Spring framework) -- I've seen a single spring config file but I am not sure if it is actively used
Jim -- the visualization code may use some libraries, but the VIVO application as a whole doesn’t use Spring
Justin -- Can you briefly list the available APIs?
There are 5 APIs listed and documented in the wiki
How am I sure I’ve found everything in the documentation? -- hard to say given the diversity of locations (vivoweb.org, the wiki, Git, mailing list archives, etc)
What is the time frame for 1.8?
looking at a code freeze in another week
The road map
How should people who are interested in adding things to the road map submit requests? And then create task groups? Will that be managed by whatever road map group is set up?
Layne -- the road map development group is not likely to be charged with implementing the process or governing/coordinating the task groups
...