How should QRiS consume RiverscapesXML?

[philipbaileynar]

QRiS needs to consume both business logic and symbology from the Riverscapes XML repository. I see two options for accomplishing this:

Solution	Advantages	Disadvantages
Duplicate the resource sync code from QRAVE and have QRiS maintain it's own copy of the resources.	Quick and easy. We have the code!	Slight code duplication (enhancements and bugs need to be performed in two places.
The QRiS plugin could have a dependency on QRAVE. i.e. Installing QRiS would automatically install QRAVE.	No duplication of code or resources.	We have never done this before there are risks and unknowns.... What if you already have a different version of QRAVE than the version required by QRiS? A bug in one cripples the other. How does one plugin use the code and resources of another?

Thoughts @MattReimer @joewheaton @nick4rivers

[MattReimer]

A few more questions:

Are we talking about doubling the code to find, load and parse business logic and symbology as well as the code to sync the network files? This is most of the QRave code no?

The whole point of QRave is that there is only ever one source of local truth and one source of remote truth when it comes to symbology and businesslogic. I worry a little about what happens if you want to develop BusinessLogic or symbology. It might not be clear which local file you're overriding.

Also, QRis doesn't need to to sync VBET businesslogic (for example). In fact, most of the synced data wouldn't actually even be usable by QRis so maybe it should filter and only sync its own stuff.

[philipbaileynar]

QRiS needs:

• to add several new riverscapes compliant project types (that will also go in the warehouse)
• display project trees for any existing project (i.e. use existing business logic)
• add several new QML symbology files that are additions to the existing symbology files. i.e. for use in RAVE.

In other words, QRiS needs are compatible with the existing RiverscapesXML contents. They simply extend the existing BL and symbology concepts. There is NO need for a separate folder for custom QRiS resources.

[MattReimer]

My spidey sense is twitching. I think we need a whiteboard and 2L of coffee to make a good choice here.

[joewheaton]

Are we talking about doubling the code to find, load and parse business logic and symbology as well as the code to sync the network files? This is most of the QRave code no?

I don't think so? We're talking about leveraging the exact same RiverscapesXML repo and standards you developed for business logic and symbology and just copying (I guess duplicating) the code that QRAVE uses to call up the RiverscapesXML into QRiS.

The whole point of QRave is that there is only ever one source of local truth and one source of remote truth when it comes to symbology and businesslogic. I worry a little about what happens if you want to develop BusinessLogic or symbology. It might not be clear which local file you're overriding.

That's exactly why we're proposing to refer to the RIverscapesXML in the same way..

Also, QRis doesn't need to to sync VBET businesslogic (for example). In fact, most of the synced data wouldn't actually even be usable by QRis so maybe it should filter and only sync its own stuff.

Actually, QRiS needs access to ALL the business logic. Whether it does this by downloading its own copy of it and syncing it like RAVE does, or by looking into RAVE's folder, or by something else is the question (I think). @philipbaileynar can clarify.

[joewheaton]

@philipbaileynar I am sort of inclined to go with Option 1. I don't see the RAVE stuff changing that much in a way that needs to be updated to QRiS. We are not talking about a tree that has all the right-click context (i.e. the places where most new RAVE features are likely to be added). All we're doing is exposing the tree using business logic and using to select projects (from warehouse or on disk) that we navigate the tree XML and then when user selects we download and add to QRiS project with RS Project Metadata.