mvextensions
[FEATURE] Simplify/Standardize DBMS Connectivity
There is some confusion and stability questions about the mvGateway. While it was a fine first effort, I'd like to take a shot at providing an alternative connection method between VSCode and any MVDBMS.
Each MV platform has its own connectivity options. Examples include QMClient, MVSP, UOJ, and UO.NET. For our purposes I think it would help to have a single API for all platforms. Rather than writing a new one from scratch, my approach would be to use Linkar. As a general purpose connectivity product, this interface would not be limited for use to this one connection type. The exact same connection can be used for any client/server interface that a developer creates.
Linkar is a commercial product. The source is not FOSS, but there is no licensing issue because mvExtensions/MVBASIC is provided under the MIT license. No cost would be associated with this. Kosday provides a single developer license completely for free, no strings attached. One advantage of this connection option is that Linkar is supported over platforms other than Windows, so it should work as well with VSCode over Linux and Mac, connecting to any local or remote MVDBMS over any OS.
In this regard, Linkar is a shim between VSCode and native connectivity options. Just like what we do now with the mvGateway, one must setup connectivity for their platforms using one of the aforementioned options, or using Telnet/SSH. The difference here is that with Linkar, this VSCode project is no longer responsible for a connectivity pipe in addition to VSCode functionality. I think that's an unnecessary and fragile binding. Support for Linkar is generously and effectively provided by Kosday. All that we would need to support here is the VSCode interface to Linkar, which is already well-documented and very simple. I think the abstraction will simplify adoption of this MVExtension as well as ongoing maintenance.
My proposal is to create the alternative connectivity method and then to add a Settings option to choose between mvGateway and Linkar. This would then not interfere with anyone's choice, only present a new option. It would also pave the way for other options. For example, if someone wants to add a hard-coded interface with QMClient, they can do so, bypassing the middleware, and the addition to Settings would be trivial. I have not yet looked at exactly how the run-time would shift to the chosen connectivity option but of course that's part of the development.
My intent in the near-term is to create this interface in my project fork, make it work, ask people to test, and then offer a PR for final merge.
In full disclosure, I do have an association with Kosday. I believe they have a fine product and I am doing what I can to support the efforts of long-respected colleagues through assistance with their product, Marketing, Sales, etc. I do not have a financial bind with them (yet) and do not stand to derive profit from this initiative, especially given that all of the connectivity is free. Assuming I do establish a closer relationship with them to receive commissions on sales, and they sell licenses based on field experiences from use with VSCode, then yes, ultimately I may earn some recompense. If you look at the VERY low purchase price and yearly subscription for Linkar, you'll see that this indeed would be nothing more than coffee money. Given that I am volunteering to code and support this interface for those who choose to use it, I hope people don't mind this potential outcome.
I'm for it! I like those guys and we've had some conversations about possibly getting them involved here, going back to the most recent Spectrum, so I think this would be a nice inroad.
There's another consideration here too, perhaps, and that's that @GrantHart and @pschellenbach are working out a standardized REST API to use for the comms/connectivity layer as an alternative to the gateway. Could be a good opportunity to help those guys out if you want to get involved in that effort!
Thanks for the support. I asked their permission to make this proposal so you now have their answer. I'll serve as their liaison with this project. :) They have offered full support for any product tweaks that we might find of value with this initiative. I've created a project board to document my progress.
About the REST API, that's exactly what I meant about allowing selectable connectivity options, and so far that makes three. As to any possible integration between the REST effort and Linkar, I'll work out the Linkar bits and then hope to check with the guys in a separate ticket to see if there is any synergy from, say, a REST interface to a server where there is then a Linkar connection into a database. I'll probably think better of this later, but at the moment I don't see an application for such a beast. :)
@MVDBMS-Solutions - issue #7 has some discussion of the REST file system API we have been working on. I believe the current gateway is implemented as a REST server acting as a middleware for native connection interfaces like QMClient. I am currently working on a compatible REST file system server for AccuTerm, which in the end I hope will provide an easy migration path for wED users to move to VSCode with this extension. Hopefully we can keep the functions for various connectivity options similar if it is not possible to use a common API.
While I don't have issues with more connectivity options, the problems that I have seen so far have very little to do if anything with MVGateway. I know that the gateway has been installed on a large number of systems as the MVON# extension without significant problems. I don't think we overreact to a couple of problems with the gateway and suggest that it isn't stable. I think that you will find that the majority of problems deal with configuration and documentation issues rather than MVGateway issues.
I haven't been able to successfully connect using the gateway for Unidata, and have futzed around quite a bit without success. Dick's document is very helpful, but when it doesn't work there doesn't seem to be much logging or tracing available. I haven't been able to get any logs showing up in c:\temp for example. On the plus side, it's motivated me to install the extension so debug mode is enabled, but that's a whole new learning curve to work through for me.
The ideal case would be native javascript open-source clients for each of the target systems, but that's a lot to hope for. I'm grateful to MVON and the folks who got everything to this point - it's very exciting, and encouraging to see...
Ian,
Unidata is the one system that I have not connected the gateway to although I believe that Grant has. I would be happy to work with you to resolve the problems you are experiencing. I would like to understand the problems you are having. Please contact me directly at [email protected]mailto:[email protected] or 214-727-1363 so that we can plan a time to do a teleconference. Where are you located?
Thanks, Dick
From: Ian McGowan [email protected] Reply-To: mvextensions/mvbasic [email protected] Date: Tuesday, October 1, 2019 at 12:00 AM To: mvextensions/mvbasic [email protected] Cc: Dick Thiot [email protected], Comment [email protected] Subject: Re: [mvextensions/mvbasic] [FEATURE] Simplify/Standardize DBMS Connectivity (#43)
I haven't been able to successfully connect using the gateway for Unidata, and have futzed around quite a bit without success. Dick's document is very helpful, but when it doesn't work there doesn't seem to be much logging or tracing available. I haven't been able to get any logs showing up in c:\temp for example. On the plus side, it's motivated me to install the extension so debug mode is enabled, but that's a whole new learning curve to work through for me.
The ideal case would be native javascript open-source clients for each of the target systems, but that's a lot to hope for. I'm grateful to MVON and the folks who got everything to this point - it's very exciting, and encouraging to see...
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/mvextensions/mvbasic/issues/43?email_source=notifications&email_token=ACOODL4OXNFXWN2S4OOKCC3QMLKODA5CNFSM4I4BUJO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD776RNQ#issuecomment-536864950, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACOODL2SIZP2MVHPUUFK5CLQMLKODANCNFSM4I4BUJOQ.
I take Dick's point about not rushing to alternatives. It seems to me that the gateway is closed source, and if it's going to be a blackbox roadblock then I think an alternative (not replacement) would be desirable to some. Yes, Grant could FOSS the gateway but that becomes another component to be maintained as a part of this project. Yes, Linkar is proprietary and will never be FOSS, but it's well maintained by a team that is highly motivated for commercial purposes to ensure its forward path, unlike any FOSS. So I'm still thinking there are good reasons for adding options.
This ticket is actually two-in-one. First, tied to the title, it's about standardizing code interfaces to whatever data access layer (DAL) that someone wants to use. Second, it's about adding Linkar as another option for DBMS access. That second item should have been a ticket of its own, but c'est la vie. I was thinking about changing the title here, but since it's still at least half accurate, I'll leave it : The primary intent is still to standardize the DAL interface, and adding a Linkar DAL is as much a new feature as it is a POC to help insure the standardization is working as expected.
@pschellenbach Every time I open WED now, I think the forward path there is to have AccuTerm open VSCode. We should definitely coordinate to ensure the REST interface (front-end) uses a new common (back-end) DAL API. With that, a user/developer should still be able to use VSCode from AccuTerm without being locked to the MVGateway.
I am very open to options and I believe that options make the product better. I just wanted to make sure that we weren’t abandoning one option for another. We could also bring Bluefinity’s mv.NET into the mix too. The major benefit that I see with Grant’s MVGateway is that it is a simple, single purposed application that is much less complex. If all you want is connectivity to your MultiValue database for your VSCode, Linkar and mv.NET as well as other commercial products are likely overkill.
From: MVDBMS Solutions [email protected] Reply-To: mvextensions/mvbasic [email protected] Date: Tuesday, October 1, 2019 at 11:10 AM To: mvextensions/mvbasic [email protected] Cc: Dick Thiot [email protected], Comment [email protected] Subject: Re: [mvextensions/mvbasic] [FEATURE] Simplify/Standardize DBMS Connectivity (#43)
I take Dick's point about not rushing to alternatives. It seems to me that the gateway is closed source, and if it's going to be a blackbox roadblock then I think an alternative (not replacement) would be desirable to some. Yes, Grant could FOSS the gateway but that becomes another component to be maintained as a part of this project. Yes, Linkar is proprietary and will never be FOSS, but it's well maintained by a team that is highly motivated for commercial purposes to ensure its forward path, unlike any FOSS. So I'm still thinking there are good reasons for adding options.
This ticket is actually two-in-one. First, tied to the title, it's about standardizing code interfaces to whatever data access layer (DAL) that someone wants to use. Second, it's about adding Linkar as another option for DBMS access. That second item should have been a ticket of its own, but c'est la vie. I was thinking about changing the title here, but since it's still at least half accurate, I'll leave it : The primary intent is still to standardize the DAL interface, and adding a Linkar DAL is as much a new feature as it is a POC to help insure the standardization is working as expected.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/mvextensions/mvbasic/issues/43?email_source=notifications&email_token=ACOODL7K47UJL2ZBZTDTDOTQMNY65A5CNFSM4I4BUJO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAB2LEY#issuecomment-537109907, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACOODL5PB2K62OZP6Z7OBODQMNY65ANCNFSM4I4BUJOQ.