MV BASIC to JS

[Dawn Wolthuis]

Does anyone know if there any MV DBMS providers who are transpiling MV BASIC to JavaScript (the new p-code) to run in the new p-machine (Google v8: browser & node.js, plus all other evergreen browsers)?

https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-JS

Does it seem like a good idea, or should we work with JavaScript (ES5) or choose ES6 or one of the myriad of other possibilities, as shown in the link about?

--dawn
--

Dawn M. Wolthuis

Take and give some delight today

[Tony Gravagno]

Dawn, something is weird about your original posting, I haven't been able to respond from the GG web UI. For anyone else who wants to respond, try email...

For various reasons I've experimented with creating a BASIC parser using Antlr (http://www.antlr.org/). That could be used to generate JS. But the high cost of development time is far outweighed by lack of interest in our industry. In short, we Can do anything, but in too many cases we simply shouldn't.

 

Once you have BASIC out of the box (translated into some other languageX, you also need to wire to a middle-tier to go back and back-end code to support it. For communicating between any language X and any MVDBMS Y, I was working on what I called mvEsperanto. That consisted of a single JS API for all MV platforms - no more of the stupidity where every platform has its own distinct API. And the same API could be used for Java, C#, PHP, etc - again, consistency across the client-side platforms too. But once again I have higher priorities, and have grown weary of fighting an industry that's a bit too eager to commit suicide.

 

Really though, BASIC applications are rich in rules and complex in their integration - which is exactly what JavaScript applications are not. I don't see any value to porting an existing app to JS to have it run outside the box - where's the value of that endeavour? Sure there are some rules that are better on the client side, and moving rules up the chain helps to eliminate some traffic, thus making for a faster app. But that kind of code is easily written in JS directly, and it's usually done in a completely different way. So again, I don't see the value in such a translation.

 

But that's just me. Have fun.

T

[Dawn Wolthuis]

To be clearer, I'm not working on this, but given that

a. JavaScript is the ONLY language with which one can do fullstack development if the browser is part of the picture

b. the above will make JS viable for many years to come

c. If you think of the browser today as something like the p-machine of yesterday, it makes sense to transpire any language you want in the picture to the p-code, or in this case, to javascript

d. Google V8/Node.js is in its infancy in the uptake for existing line-of-business software apps, but adoption is growing rapidly. Microsoft and IBM are both teaching and facilitating adoption. JS is the language in the middle tier. No C# nor Java required. 

It was starting to seem like a lot of "scripting" languages had transpilers for JS so I found this page with a list. I was surprised that it was even more than I guessed and included some flavored of BASIC, so I am curious if any of the Data/BASIC developers are interested in this trend.  --dawn 

Sent from my iPad

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Cleber Vieira Baptista]

Hi,

O4W converts Basic for JS?

Cleber

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

--

Cleber Vieira Baptista

+55

 61 8441-1663 Oi

 83 8725-9988 Oi

[Ross Ferris]

I was having the same problem as Tony in terms of responding .... maybe I'll have more luck with this shorter version. 

Around 20 years ago I got excited about the possibility of having PickBasic run as an ActiveX control inside of IE4, but given the disconnect between the client PC and the actual data, that iteration never got past the "hmmmm, I wonder" stage. Whilst I can understand the enthusiasm, I'm very happy with the way we ended up going with Visage.

Today I think we have the very best of both worlds - I can call a BASIC program from JS, and/or my Basic code can call a JS function or generate dynamic JS that is executed on the client (... which could call a BASIC subroutine, which could ...). So, if I need to access, say, a web service, I'll do that from the client (or maybe from a middleware server, or maybe from the database sever), whereas if I need to process a few million database records I'll do that in BASIC.

Tony was (obviously) on the right track with ANTLR (worked for jBase), but very difficult to make a commercial case, but a the end of the day if you were going to put the effort in I don't think a JS end target would be a worthwhile goal.

[Ross Ferris]

I know VERY LITTLE about Revelation/O4W so am more than happy to be corrected on this, but I don't believe that it converts Basic to jScript. Rather it allows you to closely integrate Basic code to a web page, which in turn can contain Java Script (certainly that was my understanding of the original Australian product).

[Ian McGowan]

I hate to seem like a wet blanket, but kind of agree with the naysayers on this one - the benefits of Pick Basic are its tight integration with the database/data model.  Basic is to Pick as T-SQL is to SQL Server or PL/SQL is to Oracle.  Not sure I see the use case of transpiling basic2js outside of the DB.

The other way round is a different question - I would be interested in running js inside an MV system, with the right libraries to handle integration to read/write/execute/call.  It would be very NoSQL - MongoDB works this way.  Then you would have js in every part of your stack - js in the browser to js in node.js in the middle tier to js in your Pick database.  Malkovitch, Malkovitch, Malkovitch :-)

[Kevin Powick]

On Wednesday, 22 July 2015 21:30:16 UTC-4, Tony Gravagno wrote:

Dawn, something is weird about your original posting, I haven't been able to respond from the GG web UI.

Same.

 

Really though, BASIC applications are rich in rules and complex in their integration - which is exactly what JavaScript applications are not. I don't see any value to porting an existing app to JS to have it run outside the box

Compiling to JS is so 2015.  The future is WASM.

https://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6

--

Kevin Powick

[Wols Lists]

On 30/07/15 00:41, Ross Ferris wrote:
> Tony was (obviously) on the right track with ANTLR (worked for jBase),
> but very difficult to make a commercial case, but a the end of the day
> if you were going to put the effort in I don't think a JS end target
> would be a worthwhile goal.

The Cache DataBasic compiler also uses ANTLR, as far as I am aware. Jim
Idle was very active in the ANTLR community when he was at Cache ...

And MaVerick used ANTLR, too.

Cheers,
Wol

[Dawn Wolthuis]

Thanks for the link, Kevin -- can't wait to work in assembly language (jk)

One line not to ignore for too long is this one --

Node is still taking over startup and enterprise web servers at a torrential pace.

Netting it out -- we can do what we need to do in JS today, but if converting an app like Adobe Premiere for the browser (THE target run-time engine in spite of native this and that), those issues will be resolved in the future. We don't need no stinkin' javascript code generators to get to node.js fullstack javascript apps today.  --dawn 

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Tony Gravagno]

I guess I'm just not as informed as I would like to be on the other DBMS options. I see "SQL through a provider into a database" as being the common model. Exceptions, as noted, include T-SQL and managed stored procs. In the case of the latter, C# is running in the DBMS rather than as a client, but the code is still almost identical to client code, establishing a connection, executing a query, and then operating on the results as a set of rows. Where I'm going with this is that this can, does, and should work exactly the same as with MV, where a remote client can execute code on the DBMS server which then calls into MV and BASIC. The heavy lifting can be distributed amongst all the tiers.

I know I'll catch heat for this but I think the desire to bring BASIC out of the box or to put other things into the box is largely due to uncertainty about how and where we can already make connections, and how to manage them efficiently. With efficient management of remote clients, middle tier providers like a web service, and server-side code in the language of your choice, we already have the functionality that people describe here. With a BASIC2JS approach, or JS execution within MV, there's a LOT of conversion going on for very little return value outside of what we're getting now for free. And that's with consideration for the technology as well as the audience.

My opinion remains that this is simply not a good idea for this environment given the low value-to-cost ratio. "Cool" doesn't justify it.

All this make me wonder what Rocket is doing with Python and their other development. Just how close to the metal is the connection point? Is this just another provider, which just about anyone can muster these days? Or is it more like a T-SQL or managed proc?  Dunno, haven't looked or asked until now.

T



On Wednesday, July 29, 2015 at 6:12:35 PM UTC-7, Ian McGowan wrote:

... I would be interested in running js inside an MV system, with the right libraries to handle integration to read/write/execute/call.  It would be very NoSQL - MongoDB works this way.  Then you would have js in every part of your stack - js in the browser to js in node.js in the middle tier to js in your Pick database.

[Dawn Wolthuis]

First a note that I did a simple reply to this post and noticed before hitting send that it was set to send a personal email just to Tony, so I went back with a reply to all and it set that up like this. So, a setting seems to have changed.

WRT BASIC compiling to JS, I was curious when seeing the large number of transpilers taking other languages to JS whether any MV DBMS provider was doing this. I have no immediate need, but I like to know the options as reuse of some existing code within node.js might come in handy. 

If using a node.js framework, such as express, sails.js, hapi, restify, etc, there are some nice libraries for developing CRUD APIs. If you had an MV DBMS at the back-end, there are not drivers for them in the list of options for any of these node.js frameworks. There is an option for Cache/MUMPS from Rob Tweed. There are often other NoSQL database options, such as MongoDB or Couchbase, or even key-value such as Redis, and, of course, there are drivers for Oracle, SQL Server, MySQL, and PostgreSQL, but I can only come with a more complex configuration for MV. 

I'll admit my ignorance so no need to refer to it nor to explain how my question here is what is wrong with our industry ;-). In other words, I hesitate to ask my ignorant question here, but...

I understand folks going directly from front-end Angular to a proprietary MV restful json web services API server when there is one. I would like to use one of the existing node frameworks in the middle tier as an API server instead, front-ending an MV DBMS.

First, which MV databases have an API server option? I saw the one for D3 -- perhaps that is available for U2 too? Cache's app server, the CSP gateway, can be used in this role too. Then you can write a typical node app with a rest api written in JavaScript and use a rest driver to pass the request to the DBMS. That doesn't seem like a speedy option as two http requests are made for each CRUD function, but maybe it would not be too awful? 

I am not technical enough to write my own drivers for node.js, but these are open source frameworks, so maybe someone else has made an MV driver already -- something similar to mv.NET but without the .NET?  It looks like each MV database would have a different way of handling a very current architecture today with node.js in the middle tier, but I don't even know how a U2 shop would do this. Has anyone given any node framework a spin in the middle tier?

There is no SQL required in such a stack at all. So, it seems like a good place for MV to play. MongoDB seems to be doing it in a way that it gets a lot of press, and it has some similarities to pick databases, but also lacks some of what we expect. What would it take for an MVDBMS vendor to make their database available to node.js in the way that mongo does?

What would be a good way to swap out MongoDB for an MV DBMS in a "MEAN" stack app?  Thanks for any suggestions or education on this topic. 

--dawn

Sent from my iPad

[Tony Gravagno]

I don't know if I've said something like this already in this thread but I know I've posted it recently somewhere...

Here's the skinny :

1) All of the MV platforms have a connectivity library like UOJ or MVSP. The connectivity method doesn't matter.
2) It's easy to wrap a web service around any of these. We've been talking about this for over a decade.
3) All JS frameworks include a web service client interface.

SO....

It's rather trivial to create a server process for any MV platform.
It's trivial to create a JS class which wraps a web service client, while exposing a platform-agnostic API.
The API for this should be very generic - don't use names like UOConnection, D3File, or QMSelect.
All invocations should be asynchronous with callbacks - a concept I demonstrated at a Pick conference back in 1999.
Such a class can be used by any JS code on a client or server tier.

OK - the dots are all connected there and the dots link an end-to-end JavaScript interface to MV exactly as you describe.
Which part needs more explanation?
Which part is inelegant or otherwise unacceptable?

If there is a doubt as to whether this would work or not, it's already been done and I called it mvEsperanto. (I've referred to it a few times over the years, receiving a stellar lack of interest - usually a result of "what the hell is he talking about?") It can work with any language (Java, PHP, Ruby, JavaScript, C#, VBA), from any tier, with any MV DBMS, and any connectivity option (MVST, mv.NET, UOJ, QMClient, etc). What stops this from seeing the light of day is the insistence from the MV industry that everything should be free. This isn't a product. By its nature much or all of the source code must be open. While "open source", and possibly "free" as in liberty, this cannot be "free" as in beer, or at least the development time can't be even if the software is. That's where this has sat for the last 5 years or so ... while we go through a new iteration every few months of "is this possible", "how can this be done", "wouldn't it be cool", and new offerings that are closed source, platform-specific, and fairly limited.

Venting on a Saturday evening...
T

[Dawn Wolthuis]

Connectivity holds some mysteries for me and I have not researched features of late for U2. It has been a while since I worked with UOJ, and that was from Java. 

How would you use UOJ without a JVM in the mix? I recall an org I worked with using pipes with perl to UniData instead of UO a decade or so ago. 

The connectivity stuff from node.js to some of the DBMS's is a mystery to me once a JVM and .NET are not part of the architecture. I typically work higher in the OSI layers (or I'm just not all that technical). How would you use UOJ with a node framework?  Would you have your API written in JS running in node talking to a JVM that then talks to U2? I would like to do better than that.

From a high level perspective, what would a developer like me, one who prefers the sys admin be done by elves at night when I'm not watching, do to expose an http json web service for U2 data for use by any client?  

Sorry to be so dense. TIA.  --dawn

Typed on a mobile keyboard

[Kevin King]

I may not always agree with TG but on this topic he's spot on: Connectivity is infinitely more valuable than translating one language to another. I'm intrigued by this mvEsperanto solution he has dreamed up and would love to know more, without asking him to give up anything proprietary, of course.

(Back to lurk mode)

[Dawn Wolthuis]

I definitely agree on the connectivity thing. I was not making a request for a transpiler but with the sheer number out there, I thought there might be one I was unaware of. 

You have been working with a PHP stack. How do you do connectivity from PHP to U2? 

Additionally, are you writing web services consumed by PHP clients? What do the pieces look like? I know how Cache MV handles that, and I've seen the d3 approach now but not U2.

TIA.  --dawn

Sent from my iPad

On Aug 1, 2015, at 9:42 PM, Kevin King <precis...@gmail.com> wrote:

I may not always agree with TG but on this topic he's spot on: Connectivity is infinitely more valuable than translating one language to another. I'm intrigued by this mvEsperanto solution he has dreamed up and would love to know more, without asking him to give up anything proprietary, of course.

(Back to lurk mode)

--

[Kevin King]

Oh I'm following you. This seemed to start as a ping to see if anyone was doing it and devolved into something entirely different. This is why I try to keep my mouth shut in here; anything I say can and will be used against me in the court of public opinion, and frankly I have enough drama already.

Having said that...

We have a number of ways to connect from PHP to U2, et al. There are the proprietary ways - i.e. Uniobjects,UOJ, even ODBC (for people who love dentists who use chainsaws), and non-proprietary ways like the Apache connector I wrote about in Spectrum a bit ago.

My personal preference is to use sockets with and without encryption as the need arises. Nearly every language and environment these days has support for sockets and many have a form of connection pooling for license management, so the rest is detail.

Yes, we are writing web services as an adjunct to writing web APIs to back end functionality. The API is the core element; the fact that it runs as a web service is merely just one possible interface to the functionality.

As to the pieces... We have a PHP object called WebConnect. It does a few things but one method specifically applicable to this discussion:

$result = WebConnect::call($subroutineName,$params)

Any time we want to call a subroutine from PHP we use this interface object. (Similar objects could be built in other languages as well.) This routine serializes the parameters into a JSON formatted string and sends it to the connected host (handled through a separate configuration object) which then parses the JSON and calls the subroutine as named. The subroutine then does what it does and sends back a JSON formatted result which is then converted into a first class PHP array that is then assigned to the lvalue.

All we ever do is call subroutines; this prevents the connector from having unrestricted access to the system. If we want to open up a system like that, we just have to create a subroutine that gives appropriate access to the people with the right credentials.

Security and state management are then added into this mix, but basically our method focuses on on moving bits with the least amount of complexity. JSON in, JSON out, and calling subroutines.

I'm intentionally avoiding value statements like "this is the best way" because frankly we had the luxury of building all this from scratch with no previous encumbrances. In our Red Leaf environment it does work well but other environments might require more complexity. I do wish more platforms supported JSON (QM rocks it BTW) but JSON support is really quite sketchy at this time. Fortunately, BASIC is still awesome and very capable for parsing.

[Kevin Powick]

On Saturday, 1 August 2015 23:49:48 UTC-4, Kevin King wrote:

  

WebConnect::call($subroutineName,$params)....

 

All we ever do is call subroutines; this prevents the connector from having unrestricted access to the system. If we want to open up a system like that, we just have to create a subroutine that gives appropriate access to the people with the right credentials.Security and state management are then added into this mix, but basically our method focuses on on moving bits with the least amount of complexity.

This is the way to do it, for exactly the reasons you state.

Now, if I were looking to completely insulate front end developers from the mysteries of MV, I would essentially "wrap" those calls in a service/API specific to the application.

--

Kevin Powick 

[Kevin King]

That's exactly the point. We can spec out inputs and outputs and the web guys only need to know the spec to achieve the objective. Thank you for mentioning this very important detail.

--

[Doug Averch]

It's not just creating an API that works with U2 that is the issue.  Just ask Tony how many technological advances he has built or knows about that have gone no where.

U2logic created an API for interfacing with U2 in 2004 using UOJ and Apache Tomcat with an API that is JavaScript based. You can can issue SELECT statements or call subroutines with full JSON control from your JavaScript source with JSON returning from Universe or Unidata. U2logic team saw Kevin King give a demo of PHP around 2008 for CMUG.  We added support for PHP about 2 days later.  Did anyone care?

Unfortunately, the U2 and pick market are too focused on the not invented here syndrome.  If your shop does not invent the technology then it cannot really be that good.  For this market to grow beyond the 100 to 200 million barrier some company needs to take this pick dinosaur and make it a bull market.

Regards,

Doug

www.u2logic.com

BTW: Dawn, U2logic showed you our API many years ago at a Spectrum conference with JavaScript and PHP interface when it was in Westminster, Colorado.

[Dawn Wolthuis]

Thanks Kevin -- That is very helpful, and you know I was baiting you a bit since I have notes related to your approach. I think you are doing very solid things with U2 connectivity. I was away from MV for a bit and should go back and read some Spectrum magazine articles, such as the one mentioned. Next time I do work with U2, I'll take a closer look. At this point, I'm working with an API approach so Angular front-end folks can "simply" use the api.

As you know, the connectivity piece might sound easy, on the one hand, but there are many details to get a solid, reliable, secure, performant app, whether with PHP or JavaScript. This layer is quite mysterious to me. I'm not one to write drivers, and I'm not all that "technical," but I think I have good instincts for solutions that will work for organizations.

I hear you regarding speaking up here. It can be exhausting. I took a break, but thought I would try it again. I think folks here mean well, and simply have different styles that sometimes inadvertently offend. I decided I had a better shot at surviving the land mines if I make clear up front, perhaps in every single post (yes, exhausting!) that I know I'm ignorant, but I do not think that I'm the problem with any given industry, that I ask questions when there is something I don't fully grok often showing my ignorance for the sake of learning something, and that there is a TON that I can learn from others. As a management consultant, I work up high in the OSI stack -- right there with end-users and management, but also with ux folks, business logic folks, data modelers, product managers, product marketing, and project managers. For anyone who brands themselves as more technical than I, I can definitely understand the post-and-duck concerns here as I often feel it myself in spite of all of my disclaimers.

cheers!  --dawn

Sent from my iPad

[Tony Gravagno]

The structure described by Kevin and Kevin is exactly what I was talking about. The WebConnect class, or whatever you want to call a self-rolled wrapper, abstracts everything down to a Call method so that there is no longer a concept of MV exposed to developers who build forward from that tier.

As to what goes behind that, it doesn't matter. If you want to use a Java-based connectivity option for your favorite MV platform then use a bridge - lookup "php java bridge" for info about calling Java from PHP. Again, all we're doing is connecting dots. Kevin said he's using sockets. OK so rather than a connectivity library provided by the DBMS vendor he's getting PHP to make a socket call which might connect to a local or remote listener. This demonstrates value in a network connection rather than requiring a JVM on whatever system is running PHP, and makes the connectivity much more versatile. It also allows that specific interface to connect to other MV platforms since Kevin is now controlling the underlying protocol.

In short - that's mvEsperanto ... to answer your question Kevin, I did exactly what you or others have done or would do in this case. The general idea of mvEsperanto is that it's not just code but a framework/API, a definition of how things fit together where the implementation for any X-to-Y topology can be written by anyone. In your case you have PHP>sockets>U2. Your WebConnect class could be implemented in any language to use that exact same socket middle-tier to U2. Then someone else could write a socket server for another MV platform to get the exact same end-to-end connectivity. Now someone else might prefer a vendor-provided pooling mechanism, and substitute the socket interface with UO or mv.NET. Someone else might prefer a web service call to make the client component look less platform-specific, and thus more appealing to other developers. The client-side code doesn't need to change at all to support a new connection method or a different MVDBMS. Any new connection mechanism can be implemented without ripping up the UI code - which is exactly what MVC/MVVM and even web services are all about. This gives us a ton of code re-usability and would serve as the base for any "how do I connect to MV from X" question.

More details in the mvEsperanto spec involve what the call looks like. Is it "Call" or "CallSub" or "CallProg"? How many arguments? Is the result passed in an in/out argument or is it the return value from an assignment? How do MV items get parsed? What about data typing and conversion of dates? What else can we do with it, like returning multiple items, or doing an Execute? These questions need to be answered in a spec so that all developers have a guideline for what's expected in their code no matter what language they're using. This is what W3C does for browser developers and what OASIS does for XML specs. I was hoping to publish details about this on PickWiki after the move to MediaWiki. I just haven't had "free" time.

HTH
T

[Tony Gravagno]

Right-on,Doug. "Not invented here" (NIH) has crippled this industry. We need the Spectrum Manufacturers' Association back. An SMA-type organization can help to define industry standards and reduce the ongoing factionalization of this tiny market. It's tough to claim to be an "industry" when everyone is going their own separate ways. As each MV vendor develops their own API and bindings we move forward in terms of modernization but backward as a whole. International Spectrum could (once again) be the base for an SMA, but it lacks that kind of power anymore, and dove-tailing with the NIH issue, I doubt any of the MV players will agree to implement standards collaboratively defined with anyone else.

Outside of the few MV forums, there's no cohesiveness to present to a mainstream audience. This is one of the reasons I'm so gung-ho on forums, social media, the wiki, and "community".  I was really hoping InterSystems would be to MV what it was to the MUMPS industry but they simply lost interest. My hope now is that Zumasys and Rocket Software will collaborate as industry leaders. Revelation brings a lot to that table too in terms of marketing to new audiences.

Broken record ... T

[Dawn Wolthuis]

Yes, and I think we can also bump up a notch to claim the entire "NoSQL" (or Not Only SQL) industry as "our industry" given that they use a data model that is very similar to Pick. I have taken several DICTs and implemented them in MongoDB, taking note of very few differences. These data models move over handily into a MongoDB "schema/model description."  The NoSQL schema, like PICK, describes, does not prescribe what the data must be. Fields are variable length. Data is in Non-First Normal Form (NF2). Developers use 2-valued logic, not 3, since they are using JSON and a typical programming language (not SQL). It is really very similar. "We" broke through, brother! 

Perhaps Spectrum could jump in and make an umbrella big enough to hold this extended family, but there are others who have or will, no doubt. When working on the MV Family Tree, I trace the history of two languages: MV BASIC, and MV Query, looking for where there are clean room versions and where code changes hands, with the Query language being the primary one I use for tracing the history. So, to broaden the family tree by these measures and show how vast our MV industry has somewhat suddenly grown (MongoDB, Couchbase, CouchDB, Cassandra, Redis, ... all have NF2 data models), all we need is to port these two languages for use with other NoSQL databases (perhaps writing to a mongoose-like CRUD API spec)  and we would have a rather natural expansion of the family tree. 

That said, I am not really missing MV BASIC as much as I thought I would (note: I've been in management for as long as I've been in MV, so I have never been a heads-down MV BASIC developer, but I have had very strong MV BASIC developers on my team). However, I have definitely missed the query language and the means of extending the vocabulary of a schema (virtual fields). Queries in MongoDB are not nearly as natural. I wrote a virtual field and cannot even query the database using that field! It simply is not a feature to do so.

To get back to my point, however, instead of lamenting the decline of anything, take a look at the huge growth in an MV-like data model over the past few years. Think of the excitement for NoSQL as an industry validation of what we have been saying. 

JSON for data exchange, like XML before it, are so much more like MV than like a SQL DBMS.

In talking with the ONgroup folks (disclosure, I'm doing a gig with them), MultiValue software apps can be decoupled from the DBMS so you can persist data in PostgreSQL, for example, and if, later on, it makes sense to go to one of the MongoDB-like products or to U2, for example, use a new driver and persist the data there. In fact, you can persist the data into two different DBMS's at the "same" time, keeping them in sync in support of different reporting and BI tools, or for integration with other apps in your organization. Database independence (polyglot persistence) is now not just all about SQL DBMS's -- you can have your MV app and use a DBMS connector of your choice, whether MV, NoSQL or a SQL DBMS. Without switching databases at all, you can have your data in Universe and SQL Server at the same time, with appropriate data transformations of your choice, using their ONsync tool for which they will soon be seeking pilot sites (if interested, you can let me know and I'll pass it along).

Once upon a time, PICK was an operating system, then it was a database, now it can support all manner of persistence (e.g. SQL, NoSQL -- including MV, which is a type of NoSQL DBMS) so that MultiValue is abstracted to a data model and related tools (MV BASIC, MV Query) supporting solid, maintainable business applications.

I think the laments that Pick folks have enjoyed making for generations now can be replaced with some joy that we seem to be leaving the "only SQL is acceptable in high society" era to one of polyglot persistence, including NoSQL / MV. In some sense, "we" broke through to the mainstream, folks!  Here here!  --dawn

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Kevin Powick]

On Tuesday, 4 August 2015 16:10:38 UTC-4, Dawn Wolthuis wrote:

Think of the excitement for NoSQL as an industry validation of what we have been saying. 

I think some of that excitement is misplaced.  I'm pretty sure I've posted this before, but here is a critical look at MongoDB from an angle on consistency of the data store.

https://aphyr.com/posts/284-call-me-maybe-mongodb

"Mongo’s consistency model is broken by design: not only can “strictly consistent” reads see stale versions of documents, but they can also return garbage data from writes that never should have occurred".

And one of my favourites from the comment section on that article:

"MongoDB? A bunch of script kiddies decided they can create a database over a cup of coffee and a few beers. This is the result. Basic database functionality is completely flawed. Not just flawed - completely, utterly flawed".

MongoDB isn't the only database that this guy looks at critically.  Check out the others examined in his blog.

--

Kevin Powick 

[Dawn Wolthuis]

First, just to be clear -- the junk data was a problem MongoDB fixed more than a year ago (before I worked with Mongo). The DBMS is much more of an infant than MV DBMS's are. I have told many MV folks that every MV DBMS I have used is better than any other NoSQL DBMS I have tried from several perspectives. From some other perspectives, no MV DBMS fits the bill quite as well as some of these others, however. If even someone as ignorant as I can use it handily from JavaScript, make web api's, and see the CRUD results in my little mongodb viewer in my editor (WebStorm), effectively doing fullstack JavaScript much as we have been doing MultiValue over the years, but with hip tools, open source libraries, on a distributed platform, with JavaScript running in the browser and in node.js, then it has something going for it. Additionally, it is open source, even if not my favorite sort of open source (AGPL). Sure, there are pros and cons of using any development stack, but a "con" of corrupt data is not acceptable and is no longer an issue with MongoDB. 

Once there is an MV DBMS that is as easy for me to use within (something similar to) the MEAN stack as Mongo is, I would like to take a look. We (the MV community) have a lot to offer within the NoSQL space, once we recognize that we could play in that larger sandbox and bring some good, solid approaches and tools with us. For now, we can use MongoDB with fullstack JavaScript much as we would use a PICK database with MV BASIC, but with the added complexity and feature-set of distributed systems -- the app can then run in a browser, whether on mobile or desktop, for example. 

I'm not about to write DBMS drivers. I'm not as clever as Kevin K in writing a library using sockets into U2 from PHP, so I still don't know how Rocket would have us do node.js to U2 if we do not want .NET nor a JVM in the mix. It's just too hard for a peasant like me, but MongoDB is not. smiles.  --dawn

[Tony Gravagno]

On Tuesday, August 4, 2015 at 2:33:23 PM UTC-7, Dawn Wolthuis wrote:

Once there is an MV DBMS that is as easy for me to use within (something similar to) the MEAN stack as Mongo is, I would like to take a look.

The path has been described almost in detail in this thread. It's all free. Anyone with the skills can write the code. No matter what is available there's always going to be someone asking for someone else to write the detailed code for them, and at no cost.

Look, this industry just doesn't work like that. The mainstream has "buzz". We do not. People in the mainstream are motivated to pick up FOSS challenges because they perceive benefits. In mvLand, FOSS falls on its face as a nothing more than a curiosity - because everyone wants to take and almost no one wants to give or even use the FOSS that's available. So while some of us do contribute FOSS, it's not used, so we're left wondering why we waste our time. That leaves you wondering why there's so little FOSS, and looking to the MVDBMS providers to publish everything for you.

You can hint at the MVDBMS providers to write this stuff for you and to make it as easy as any other platform, but that will only happen on a scale of years, if at all. In the mainstream there are companies who approve employee time to work on FOSS from which they benefit. There are companies dedicated to publishing FOSS for the masses in return for compensation from a few motivated corporate entities who don't want internal people working on it. The FOSS model is that you either have time or you have money, but you will spend one or the other. Spend neither and you get nothing. So here we are. The MV industry simply does not participate in the FOSS model as they do for MySQL, Apache, MongoDB, etc. For this reason the "make it easy and I'll take a look" posturing is nothing but fluff. It won't happen. Use the tools that exist, pay someone to help, or simply accept that you're not going to get the shiny toys.

 

We (the MV community) have a lot to offer within the NoSQL space, once we recognize that we could play in that larger sandbox and bring some good, solid approaches and tools with us.

Until the MV industry learns how the rest of the world works, we're never going to be able to play outside of this little sandbox. See how gracious a response you get from anyone outside of this community when you suggest that all of the free tools aren't good enough - that you want people to do even More for you in their "free" time before you decide the platform might be worth your consideration.

 

For now, we can use MongoDB with fullstack JavaScript much as we would use a PICK database with MV BASIC, but with the added complexity and feature-set of distributed systems -- the app can then run in a browser, whether on mobile or desktop, for example. 

And you can do the same with MV if only you'd follow the breadcrumbs dropped in this thread.

 

I'm not about to write DBMS drivers. I'm not as clever as Kevin K in writing a library using sockets into U2 from PHP, so I still don't know how Rocket would have us do node.js to U2 if we do not want .NET nor a JVM in the mix. It's just too hard for a peasant like me, but MongoDB is not. smiles.  --dawn

So pay Kevin for his tools - or pay anyone else who has already done this over and over again. Pay with pizza or coffee. Pay with your time on some completely unrelated effort. Pay by motivating other people to contribute their time toward something you (and you alone it seems) want. Pay-forward by participating in the model. But please stop asking for solutions and then coming up with random reasons why the solutions you're provided are inadequate. Take the solutions you have and move forward. Take the free ones and when you find out they're inadequate for given environments you might decide to look into one of the for-fee options which eliminate the issues - someone will be happy to charge you to make things easier for you. Replace solutions later if they're inadequate. That's how the mainstream works - they don't kick tires on a car lot for 20 years and then lament that they don't know how to drive. They build on existing tools and skills and everyone moves forward together.

T

[Kevin Powick]

On Tuesday, 4 August 2015 19:58:44 UTC-4, Tony Gravagno wrote:

 

The FOSS model is that you either have time or you have money, but you will spend one or the other. Spend neither and you get nothing. So here we are. The MV industry simply does not participate in the FOSS model as they do for MySQL, Apache, MongoDB, etc. For this reason the "make it easy and I'll take a look" posturing is nothing but fluff. It won't happen. Use the tools that exist, pay someone to help, or simply accept that you're not going to get the shiny toys.

Perfectly stated.

--

Kevin Powick 

[Dawn Wolthuis]

Sure, if I were working with U2, I would definitely check out Kevin's toolset more closely. I'm not and I know the options in Cache' -- they have more of this stuff built in than some other DBMS's do. If starting from scratch, then open source looks more attractive, at least from some perspectives.  --dawn

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Wols Lists]

If you get a tool (for free) that does 90% of what you want, don't moan.
Just fix it to do the 10% that it doesn't, and pay forward by setting
that free too (it's NOT Open Source if the licence says you MUST set it
free ...).

(And if you have money not time, just contract one of the tool
developers to do your job for you. That way you get what you want
quickly and efficiently, and they get what they want/need (ie a
paycheque) too :-)

And often it's 99% and 1%, not 90 and 10.

Cheers,
Wol