JBrowse team maintaining Apollo

[Robert Buels]

Hello all,

With Nathan transitioning to a new position, I want to check in with all of you and let you know that the JBrowse team is committed to continuing ongoing maintenance of Apollo. We will answer mailing list questions, make bug fix releases, and be available to help, just as Nathan always has.

However, nobody on our team is as much of an expert on Apollo as Nathan, so please bear with us! We might not be quite as responsive and knowledgeable as he was.

If you are an experienced Apollo user, or have helped develop Apollo in the past, please consider helping us out by chiming in on the mailing list when you think you might be able to help!

That's the bad news. Now for the good news!

The team is working hard to build the next generation of Apollo, which we hope will be a huge leap forward in annotation editing. It will include widely requested features like combining synteny views with annotation editing, the ability to directly edit local GFF3 files, and the ability to run as a desktop application without requiring a server. So that's something to look forward to!

We just might struggle a bit to keep up with the mailing list. Thanks for your patience.

Rob Buels
JBrowse Team Lead

[Helena Rasche]

Hi Robert,

Does this mean there will be less focus on apollo as a collaborative, real time server? Or just a benefit that's inherited from (I'm assuming) updating to jb2 eventually?

Synteny views will be a game changer, I'm incredibly excited! Looking forward to more people working on apollo again!

Ciao,
Helena

--
To unsubscribe from this group and stop receiving emails from it, send an email to apollo+un...@lbl.gov.

[Robert Buels]

Great question. We still envision Apollo as primarily a real-time collaborative annotation platform, we just have some user communities, particularly those coming from Artemis, that would like to have the ability to just quickly edit some local files on their own machine without needing to deploy a server. And for the next generation architecture, it’s not going to be that much additional code to support that.

But for users that want real-time web-based collaboration, a server will always sit at the heart of the system. We have been thinking a lot about ways to make Apollo even better for cloud collaboration, and the primary areas of improvement we have identified so far are: ease of deployment and administration, viewing and undoing changes, and general speed and responsiveness of the server (the current Neo4J work is already making great progress in that area).

Does that sound like a good list of priorities for the server? I’d like to hear any other pain points or ideas for improving it. We are working on designing the new client/server architecture for the next 10 years right now, so this is a perfect time for users and collaborators to shape the overall direction of things!

Rob

[Helena Rasche]

Hey Rob,

Ahhh that's reassuring to hear! Yeah, I've had users like that as well, mostly tried to give them more ways to get their data into apollo but a desktopified version sounds nice too!

Can't speak for other admins but deployment has been pretty painless for me. I've got a jenkins job that builds WARs that we throw on to a tomcat server. I used to deploy via the docker containers and that was even simpler. We've all got different auth systems but by providing remote_user auth it works for all of us with little effort on the apollo side, so I'm quite happy there.

But for administration, improvements there would be amazing! Managing users/groups/permissions on organisms was always a nightmare, Anthony Bretaudeau and I've written lots of stuff over the years to work around pain points there. As a crusty old admin I'm a bit terrified of graph databases and their scalability when I'm so familiar with chado/postgres but great to hear it's making improvements! Maybe it'll be the answer to all the speed issues.

Thanks for the warm response. This is very encouraging!

Ciao,
Helena