A hobby qm/ScarletDME fork

[Donald Montaine]

I have been working on a fork called 'sd', for string database.  While keeping the copyright information, I have worked on renaming everything, including variables, that included 'qm' to ''sd'.  The database installs to /usr/local/sdsys, and the executable is 'sd'.  The only thing I haven't been able to rename is QMSYS.  I even have the QMSYS item in the sd.conf file pointing to /usr/local/sdsys.  I have tried everything I could think of to rename QMSYS and @qmsys, but in every case the ATVAR program in GPL.BP refuses to compile if QMSYS is changed to SDSYS

The other thing I have done is remove some functionality; the TAPE system, the PROC capability, all Windows specific code, and Windows specific modules like PASSWD. This is a LInux specific database on a diet.  My goal is to remove legacy features that are not needed and perhaps to remove the Pick related functions and retain the Prime-like features and improvements.

So, the upshot is, if anyone knows how to rename the QMSYS @ variable, I would really like to know.  Or if anyone has some ideas about other functionality that could be removed or would like to try this version out, just let me know.  The installer is similar to the installer I made for ScarletDME with some small improvements.

[Wol]

On 11/01/2024 23:25, Donald Montaine wrote:
> My personal goal is to create a simple database that might be appealing
> to younger users more than existing multivalue users. Hence, removing
> some features.  The more that is in the system, the more that has to be
> documented, and the more complex it seems to new users.

I think removing features is a mistake. Look at what you think younger
users want. Add that. Document just the features you think these people
need as a "getting started" guide. Then just say "there are other
features available.

I agree with you about Pr1me, though. I think INFORMATION was very well
thought out and designed, and there you go ...

What I want to do, is get this into LibreOffice. The big problem we
have, is getting people to understand the "a relational row is an MV
Array". The trouble is visualising an array is hard, and most people are
visual...

Cheers,
Wol

[Donald Montaine]

For people who want full open-source multi-value, there is ScarletDME.  I am trying to do a rethink and do something different.  For example, I may allow some features to be reinstalled, as I have removed nothing from the c-code.  The features I am removing are implemented in Basic, and could be easily re-installed.  For example, reinstalling PROC is 1 GPL.BP file, the TAPE system about 5 files and some VOC entries.

The other thing I am planning to do is integrate tightly with operating system tools, use 'less' to scroll text files, use 'micro' as the default code editor, use 'lynx' to display html documentation pages, use 'mc' as a file browser, etc.   Also, I eventually want to allow a user to choose OS tools to be integrated into the system if they don't like the defaults.  For example, Geany with source code highlighting could be an option if they don't like micro.  The idea is that the base system will install and have a lot of functionality without a GUI, but that the user can opt to use GUI tools, if appropriate.

And, since this is for fun, I will focus on Debian compatibility.  Others could modify to work on Arch or Fedora, but a Debian console system that uses 'sd' as the default shell is my eventual goal with additional tools available if installed on a GUI capable system.  I would like eventually to build a Debian based console distro with 'sd' and related tools all baked in and ready to run, just download the disto and go, but that may be wishful thinking. It would be great if it recompiled to run on Arm systems as an embedded database, but that is probably even more wishful thinking.

As I said at this point, this is a hobby. The idea is to build the system that I would want, and if others are interested in the result, that will be a bonus.  So one thing that I am doing, just because it is what I have always wished for, is abandoning the 80x24 console size for 120x36.  It works so much better for the integration of lynx, less and micro.  And I will be adjusting the included features such as LISTF to take advantage of the larger display space. 

[Donald Montaine]

I have finished the first stage of my development of SD.

The download link is: https://u.pcloud.link/publink/show?code=XZ5VGX0ZAe4Yi5kx3Sugo8wyRjP1yRohFWmy

As far as I can tell, SD will cohabit peacefully with existing QM and ScarletDME installations.

Change Log:

---------------------

SD, the String Database is based on code originally released under the
GPL license in 2007 as a GPL release of the OpenQM database. Later
on, that code was forked and modified. The result became the ScarletDME
database.  It was a 32 bit only database until 2022 when the first
iteration of the 64 bit version was released.

SD is based on the 64 bit code in the geneb/ScarletDME github repository
as of the end of 2023.

2024-01-15 In creating SD the following changes have been made:

Some features have been removed. These include :
1 the Big Letter capability for large print titles on printed reports
  and terminal displays.
2 The package capability that allowed for installation of third party
  packages in the original commercial product.
3 TAPE related packages that included the account and file save and
  restore features.
4  PROC capability
5 COPYP functionality (COPY using Pick syntax).

The SD_SHM_KEY and SD_SEM_KEY offsets have been changed so that SD
can be run in parallel with commercial and open source databases that
use the same underlying architecture.

The sockets used for the API and telnet access have been changed:

The telnet socket from 4242 to 4244

The API socket from 4243 to 4245

The original database was called OpenQM and is still available as a
commercial product from Rocket Software.  For SD, the original QM
branding has been entirely removed.  Even internal variables and program
and file names have been changed to reflect the SD branding.

Some references to ScarletDME and Ladybridge Software have been
removed.  Copyright statements have been retained.

The default location of the database has been changed to
/usr/local/sdsys.

The default terminal type is Linux and the default terminal size is 120x36.

The C and Basic object code is included in the download.  To install without

recompiling everything, comment out the Make -B command and the two

lines  containing FIRST.COMPILE and SECOND.COMPILE respectively.

This database is in development. So far everything I have tested seems to

work as expected. However, I'm sure there are things that need to

be found and corrected. Other testers are appreciated.

Send comments and errors to sd.string.database at gmail dot com.

[Donald Montaine]

I had to make a small modification to the c code to change the sd server port number.

The new link is: https://u.pcloud.link/publink/show?code=XZ7Q7V0Z1DRXpIytpHLEzrd03wQFbBR7fmiX

[Donald Montaine]

Learned something new.  By sharing the pcloud directory rather than the individual file, I no longer have to post a new link every time the file changes.  I have finished a lot of the housekeeping on the code base and made changes to simplify the installers.

The current version is 0.6.1. The directory link is: https://u.pcloud.link/publink/show?code=kZL58V0Z9wXWbRq9r88aPtNBpMe4rh9drHgV

Just click on the file name and it will download to your computer.

[Donald Montaine]

Just uploaded SD v0.6.2 with the following new features

(mab) Corrected issues with C code that were generating errors during make
(dsm) Updated GPL.BP CONFIG to use 'less' to display the licence & contrib files
(dsm) Updated all sentences in SD.VOCLIB for larger terminal display
(dsm) Added a globally cataloged shell for the micro console based editor

 -- to use enter MICRO <FILENAME>  <RECORDNAME> at TCL
(mab) Replaced hard coded hex values in GPL.BP with @VM and other hex alternatives
(mab) Fixed possible endless loop in DELETE-FILE

The directory link is: https://u.pcloud.link/publink/show?code=kZL58V0Z9wXWbRq9r88aPtNBpMe4rh9drHgV

[Steven Martin Trimble]

Great work sir Don!

CDMI

Steven Trimble

(501) 772-3450 cell/text

cdm...@gmail.com

--
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
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/80f7c92b-868b-48bf-99af-5d78e10c9910n%40googlegroups.com.

[jim stephens]

Thanks for the work on SDME.  I'm curious if you are on the Discord for SDME?  Or want to be.  This work should be shared over there as there are a number of people there who I'm sure would be interested.

thanks

Jim

Scarlet DME discord is here

https://discord.gg/8wTNpgDJ

On Mon, Jan 22, 2024 at 11:54 PM Donald Montaine <dmon...@gmail.com> wrote:

[Donald Montaine]

I'm not on Discord at this point.  I have actually turned my attention to the SD port.  I was looking for a backend for some utilities I am writing in Gambas 3 and wanted to move some issues along at a faster pace. 

Nextjob and I have made some significant progress on the port.  I have set up a new repository:  https://github.com/dmontaine/sd.  It contains the code that we are currently working on and will be the basis for the next release, SD.0.6.3, and future releases after that. We would love suggestions on impovements to be made, new features to be developed, contributions of any code that would extend the project. and help coding or creating documentation, if anyone is so inclined.  SD is in active development, contributions will be quickly evaluated and accepted, if appropriate.  And, thanks to the developers of OpenQM who released the original code as open source and to the developers of ScarletDME who created the 64 bit port that we have used as the springboard for our development work.

SD can be much more.  It all depends on community support.

[John Stokka]

I'm thinking pretty seriously about forking off the 64-bit version and creating a new commercial version to create some competition in the marketplace.

I own the domain name MVOPEN.ORG.

Thoughts?

In Christ,

John R. Stokka

515-707-7106

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/CAN6xUzfjTPkz9MD0AK5OzOu8ObsupdmMg%2B7zvUsXr-fMoE9W%3DQ%40mail.gmail.com.

[Brandon Robinson]

We had similar thoughts here. I would enjoy discussing that with you if you are ever interested. We have pushed a few updates to Scarlet over the past year to help make it more compatible with other MV platforms also. 

___________________

Brandon Robinson

Head Geek - RDM Infinity

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/CANhQ6YikgGQbeS5aDve%2Bd1iqwmMYHHZLx8HSNNanZ35_%3DtKQ0Q%40mail.gmail.com.

[geneb]

On Wed, 20 Mar 2024, John Stokka wrote:

> I'm thinking pretty seriously about forking off the 64-bit version and
> creating a new commercial version to create some competition in the
> marketplace.
>
> I own the domain name MVOPEN.ORG.
>

As long as you follow the GPL license, that's perfectly acceptable.

However, instead of putting effort into a fork of the 64 bit version of
ScarletDME, why not just work on that instead?

tnx.

g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!

[Donald Montaine]

I'm not sure how a commercial fork of either QM GPL or SD would work.  QM GPL is released under GPL 2.0 or later, SD is released under GPL 3.0 or later.  In both cases, any modifications to the code have to be released under a compatible open source license.  Some products, like MySQL are released under dual open source / commercial licenses.  But that only works for the company or person who holds the original copyright.  All open source downstreams are really limited to open source licenses.

SD was forked because we wanted to go in a different direction.  For an open source product that aims for compatibility with existing QM or other MV products, contributing to QM GPL is the way to go.  SD is really only for people who want to experiment with a multivalue database that does not necessarily follow all the historical presidents but is still largely familiar to any MV user.  For example, in the upcoming 0.6.3 release, we have made choices that enhance security, but remove some historical capabilities.

[Wols Lists]

On 21/03/2024 01:08, Donald Montaine wrote:
> I'm not sure how a commercial fork of either QM GPL or SD would work. QM
> GPL is released under GPL 2.0 or later, SD is released under GPL 3.0 or
> later.  In both cases, any modifications to the code have to be released
> under a compatible open source license.  Some products, like MySQL are
> released under dual open source / commercial licenses.  But that only
> works for the company or person who holds the original copyright.  All
> open source downstreams are really limited to open source licenses.

It would work the way most of these things work. You would sell support
contracts. The fact the underlying product is GPL wouldn't matter.

Take for example my employer. They prefer to buy OpenQM than use
Scarlet, simply so they have someone to shout at if it breaks.

And as far as the GPL goes, there's nothing stopping people selling
products written in BASIC that run on top of Scarlet. Ship it as a
separate product, with its own installer, and there's no need for it to
be GPL. You could ship binary-only, though I don't think there's that
much benefit doing so.

And then, I've been vaguely thinking about porting OpenQM to Rust. Just
insist that all Rust code is dual-licenced MPL/GPL, and then when it's
fully ported you can use it as MPL rather than GPL - rather like
LibreOffice is licenced.

Cheers,
Wol