Custom packages and procedures per Office

[krowvin]

If office XYZ has their own service/oracle user for example wm_XYZ that contains packages and procedures within their local database.
Would the expectation be that those packages would go away when moved to the cloud?

I will attempt to not bring multiple discussions into the primary question that I have:

Can offices have their own endpoints within CDA?

Some thoughts on this:

• Offices would potentially need to maintain these endpoints
• Offices would be responsible for updating anything outside major CDA overhauls (or completely maintain)

Why?

• Allow offices to build queries on the database instead of multiple fetches for various data
• Provide districts with a means for building custom solutions for their data retrieval needs within the API
  • Could add errors to the overall project
  • Might be hard to enforce patterns/standards
• Encourages offices to do work within the API, we could then chose to merge any changes into the primary endpoints

There's an understanding that CDA should work for all.

If a district is doing X, everyone should be able to also benefit from X, otherwise, why have X?
and
We are doing X to get Y, but really we could be using CDA to get Y

Recently a draft email was sent out regarding the early stages of API improvement.
I imagine this could also be apart of that, but I thought I would ask here.

[DanielTOsborne]

Whether or not custom endpoints should be included into the base CDA depends on their purpose IMO.
Something fairly generic, with existing CWMS API calls, such as rating table access, makes sense to add.

However, something office specific, such is my custom implementation of COOP detection with complementing PL/SQL package, isn't something that really belongs in CDA proper, even if other offices may find it useful.

I'd like some plugin interface, like we have in OpenDCS.

Whether these plugins can be separate from the CDA installation, or still require source for compiling is up to implementation.

Something that lets you declare:
/my-custom-endpoint => spk.cda.plugin.MyCustomEndpoint
with minimal (if any) modification to CDA's sources.

This lets CDA be the router, and wrapping all necessary items such as authentication, and pass it all to the plugin. From that point, the plugin does what it needs to do.
This keeps excess code out of CDA that doesn't need to be there, but still provides a stable(-ish) plugin API.

[MikeNeilson]

Hmm, that's interesting. And has the same affect, however given the nature of CDA and it's intent (conceptually be the one way in even if multiple instances) I wonder if it might be easier to just having things in directly; but that also means it's required in some way.

But yes, the COOP detection wouldn't make sense. The idea is more ways of extracting data.

The question really becomes what is easier for our community. If it doesn't need the performance of a raw query the API should just be used. But query is needed that is an extra layer of abstraction.

[MikeNeilson]

though really it's just taking the data source on call, and telling Javalin "hey, I'm here" so that might be the right way to go even if everything was within the same source tree.

[krowvin]

I like Daniel's idea. Give an interface of sorts for people to point CDA at something they need (securely) without having to actually develop on CDA.

At least that's how i'm reading the implementation of a Plugin API.

Daniel I assume you mean similar to the algorithms within OpenDCS? Or is there some other plugin interface i'm not privy to?

[DanielTOsborne]

I like Daniel's idea. Give an interface of sorts for people to point CDA at something they need (securely) without having to actually develop on CDA.

At least that's how i'm reading the implementation of a Plugin API.

Daniel I assume you mean similar to the algorithms within OpenDCS? Or is there some other plugin interface i'm not privy to?

Well, it would have to be designed, like the OpenDCS API was designed for it.

The question really becomes what is easier for our community. If it doesn't need the performance of a raw query the API should just be used. But query is needed that is an extra layer of abstraction.

A little off topic, but since you mentioned it:
I asked about performance before, and was more or less told there wasn't any concern. I always suspected there was though.
When you're making hundreds of calls in a few minutes to fetch thousands (or tens of thousands) of time series values, I do expect some performance hit.