Hello all

[Peter Walter]

All,

I am a ScarletDME newbie, and I joined this forum today.

I have been a fan of PICK-derived programming languages and databases since the early 1980's. However, none of the multivalue variants and flavors have
ever contained all the features and tools I would like to see in a modern multivalue development environment, although certain features of U2 and Advanced Revelation
have made those implementations my preferred mv databases. But, there are a lot of features I have desired that the commercial databases don't seem interested in adding - so, for several years now, I have been toying with the idea of creating a dual-licensed multivalue database and development environment with advanced features.

To avoid re-inventing the wheel, I researched open-source multivalue implementations, and came across OpenQM and ScarletDME. However, I am not quite clear as to why the ScarletDME fork exists (since OpenQM still seems to be active), and I haven't found a decent writeup on OpenQM, or on what features ScarletDME  has implemented differently or in addition to OpenQM. If I overlooked the documentation in plain sight, I apologize.

Could you guys please point me to appropriate documentation?

Peter

[geneb]

On Fri, 21 Jun 2013, Peter Walter wrote:

>
> To avoid re-inventing the wheel, I researched open-source multivalue
> implementations, and came across OpenQM and ScarletDME. However, I am not
> quite clear as to why the ScarletDME fork exists (since OpenQM still seems
> to be active), and I haven't found a decent writeup on OpenQM, or on what
> features ScarletDME has implemented differently or in addition to OpenQM.
> If I overlooked the documentation in plain sight, I apologize.
>

Up until recently, only ScarletDME had native IPv6 support - Glen and I
did that a few years ago. The OpenQM you see "current" is _not_ the GPLed
version. The GPL version of OpenQM wasn't updated past v2.66.

The short version of the story is that I didn't care for how Ladybridge
handled the OpenQM GPL release. It presented a far too confrontational
face to the user. One thing led to another and due to an apparent
miscommuniction, I blew my stack at Martin (stupidly and publicly - he
didn't deserve it) and the ScarletDME fork happened. At that point we
built the build system and moved things to SVN. When the webserver fell
over, I pushed it all to github to make sure it didn't get lost.

Welcome to the zoo! We're happy to have you! :)

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://www.scarletdme.org - Get it _today_!

[Peter Walter]

On 6/21/2013 9:49 PM, geneb wrote:
>
> Up until recently, only ScarletDME had native IPv6 support - Glen and
> I did that a few years ago. The OpenQM you see "current" is _not_ the
> GPLed version. The GPL version of OpenQM wasn't updated past v2.66.

Ok. I get it now.

>
> Welcome to the zoo! We're happy to have you! :)

Thanks! I hope I will make a useful contribution to the project. I will
review the OpenQM 2.66 docs and then post further.

Peter

[Peter Walter]

All,

I have been reading the OpenQM 2.6-6 documentation, and I like it. I
hope my search for a compatible project has found a home in the
ScarletDME fork :-)

I have a few preliminary questions. I apologize if I missed any relevant
answers on the forums or in the documentation - I am still reading the
docs, and feeling my way around.

(a) OpenQM is now at 3.0-8, 11 releases ahead of ScarletDME based upon
OpenQM 2.6-6. Is that correct?
(b) Is ScarletDME a "true" fork, only retaining backward compatibility
with 2.6-6, or is forward compatibility to any arbitrary release of
OpenQM desired or contemplated?
(c) If forward compatibility is desired or contemplated, Is there an
existing roadmap to reach feature parity, or does a roadmap need to be
created?
(d) How do y'all feel about future changes that would not be compatible
with OpenQM? In other words, Are y'all willing to "freeze" OpenQM
compatibility to any particular release, and then (possibly) diverge
ScarletDME going forward?
(e) I have "met" Gene on this project. are there other active
participants working on moving ScarletDME forward?

Peter

[geneb]

On Sun, 23 Jun 2013, Peter Walter wrote:

> I have been reading the OpenQM 2.6-6 documentation, and I like it. I hope my
> search for a compatible project has found a home in the ScarletDME fork :-)
>

\o/

>
> (a) OpenQM is now at 3.0-8, 11 releases ahead of ScarletDME based upon OpenQM
> 2.6-6. Is that correct?

Correct.

> (b) Is ScarletDME a "true" fork, only retaining backward compatibility with
> 2.6-6, or is forward compatibility to any arbitrary release of OpenQM desired
> or contemplated?

The idea was to remain at feature parity with the commercial OpenQM
product while adding additional features as we saw fit. That's how the
IPv6 implementation happened. It took OpenQM two or three years to add
IPv6. I would _really_ love to see pure 64 bit support added. It will
build under a 64 bit system, but due to the object files for all the BASIC
compiled code being 32 bit, the wheels fall off pretty quick when you
start the system.

> (c) If forward compatibility is desired or contemplated, Is there an existing
> roadmap to reach feature parity, or does a roadmap need to be created?

I think it would be great, but there's been no organized effort in that
direction.

> (d) How do y'all feel about future changes that would not be compatible with
> OpenQM? In other words, Are y'all willing to "freeze" OpenQM compatibility to
> any particular release, and then (possibly) diverge ScarletDME going forward?

I don't have a problem with diverging at all, but others should comment as
well.

[Ashley Chapman]

Hi Peter,

I have been reading the OpenQM 2.6-6 documentation, and I like it. I hope my search for a compatible project has found a home in the ScarletDME fork :-)

It is the most complete opensource multivalue implementation that I know of.

I have a few preliminary questions. I apologize if I missed any relevant answers on the forums or in the documentation - I am still reading the docs, and feeling my way around.

(a) OpenQM is now at 3.0-8, 11 releases ahead of ScarletDME based upon OpenQM 2.6-6. Is that correct?

Yes, but we have added some of the essential enhancements that Ladybridge added to OpenQM.  Generally, this "old" version is not a great problem, unless you find that you have specific requirements or want to write an application that takes advantage of some new feature in OpenQM.  If you do find this to be the case, then the source code in scarlet is fairly small and simple to modify.
 

(b) Is ScarletDME a "true" fork, only retaining backward compatibility with 2.6-6, or is forward compatibility to any arbitrary release of OpenQM desired or contemplated?

Yes it is true fork.  Also any application source code written for Scarlet should compile under any of the more modern OpenQM versions.  Thus it is forward compatable.  Do you have any specific compatability requirement, or are you just asking so as to understand the situation clearer?
 

(c) If forward compatibility is desired or contemplated, Is there an existing roadmap to reach feature parity, or does a roadmap need to be created?

It's not being actively progressed.
 

(d) How do y'all feel about future changes that would not be compatible with OpenQM? In other words, Are y'all willing to "freeze" OpenQM compatibility to any particular release, and then (possibly) diverge ScarletDME going forward?

I've no problem with this notion, but it would probably be wise (and probably easy) to make any divergence an optional setting.  We have done this for other enhancements, I believe.
 

(e)  I have "met" Gene on this project. are there other active participants working on moving ScarletDME forward?

I use it for some active clients as an aplication server.  These systems are activly maintained, but I don't actually have any need to enhance Scarlet.  Thus my contributions have been quite minimal of late.  I do however "curate" the Google group.

Welcome to our very tiny circle!

Ashley Chapman

[Peter Walter]

On 6/23/2013 4:37 PM, geneb wrote:
>> (b) Is ScarletDME a "true" fork, only retaining backward
>> compatibility with 2.6-6, or is forward compatibility to any
>> arbitrary release of OpenQM desired or contemplated?
> The idea was to remain at feature parity with the commercial OpenQM
> product while adding additional features as we saw fit. That's how the
> IPv6 implementation happened. It took OpenQM two or three years to
> add IPv6. I would _really_ love to see pure 64 bit support added. It
> will build under a 64 bit system, but due to the object files for all
> the BASIC compiled code being 32 bit, the wheels fall off pretty quick
> when you start the system.

I haven't yet downloaded the source code, but I assume that ScarletDME
programs compile to bytecode; and that ScarletDME is written in C. Is it
just that the ScarletDME source needs to be modified and recompiled for
64-bit, or is it more complicated than that?

>
>> (c) If forward compatibility is desired or contemplated, Is there an
>> existing roadmap to reach feature parity, or does a roadmap need to
>> be created?
> I think it would be great, but there's been no organized effort in
> that direction.

I will review the changelogs for the OpenQM releases and build a list of
changes; from the list we can decide what, if any, changes will go into
a roadmap.

I haven't seen anything in the documentation related to user interface
features beyond the standard tty capabilities. Does ScarletDME have any
native or add-on capabilities to create user interfaces for X server,
web browsers, or Windows presentation services? How are GUI programs
currently being used with ScarletDME?

Peter

[Peter Walter]

On 6/23/2013 5:23 PM, Ashley Chapman wrote:

(a) OpenQM is now at 3.0-8, 11 releases ahead of ScarletDME based upon OpenQM 2.6-6. Is that correct?

Yes, but we have added some of the essential enhancements that Ladybridge added to OpenQM.  Generally, this "old" version is not a great problem, unless you find that you have specific requirements or want to write an application that takes advantage of some new feature in OpenQM.  If you do find this to be the case, then the source code in scarlet is fairly small and simple to modify.

Is there a list of the enhancements that have already been added?

 

(b) Is ScarletDME a "true" fork, only retaining backward compatibility with 2.6-6, or is forward compatibility to any arbitrary release of OpenQM desired or contemplated?

Yes it is true fork.  Also any application source code written for Scarlet should compile under any of the more modern OpenQM versions.  Thus it is forward compatable.  Do you have any specific compatability requirement, or are you just asking so as to understand the situation clearer?

I was asking whether the ScarletDME project was contemplating supporting newer OpenQM features at some point - in other words, if it was desirable that (say) OpenQM 3.0-8 programs should eventually run on ScarletDME. Based upon your and Gene's answers,  I understand the answer to be "possibly desired but not contemplated".

Welcome to our very tiny circle!

Thank you very much.


BTW, I have completed reading the documentation - and I am very surprised at the power and capabilities of ScarletDME. A lot of the functionality I was contemplating adding is already in there, but I think it needs to be promoted better. I will be making suggestions in that direction as we move the project forward.

Peter

[geneb]

On Mon, 24 Jun 2013, Peter Walter wrote:

>
> On 6/23/2013 4:37 PM, geneb wrote:
>>> (b) Is ScarletDME a "true" fork, only retaining backward compatibility
>>> with 2.6-6, or is forward compatibility to any arbitrary release of OpenQM
>>> desired or contemplated?
>> The idea was to remain at feature parity with the commercial OpenQM product
>> while adding additional features as we saw fit. That's how the IPv6
>> implementation happened. It took OpenQM two or three years to add IPv6. I
>> would _really_ love to see pure 64 bit support added. It will build under
>> a 64 bit system, but due to the object files for all the BASIC compiled
>> code being 32 bit, the wheels fall off pretty quick when you start the
>> system.
>
> I haven't yet downloaded the source code, but I assume that ScarletDME
> programs compile to bytecode; and that ScarletDME is written in C. Is it just
> that the ScarletDME source needs to be modified and recompiled for 64-bit, or
> is it more complicated than that?

It's been a while since I looked at it, but the 32 bit compiled byte code
does not work with a 64 bit running system. It may be as simple as
writing a conversion utility that will generate a set of 64 bit object
code files based on the 32 bit object files.

> I haven't seen anything in the documentation related to user interface
> features beyond the standard tty capabilities. Does ScarletDME have any
> native or add-on capabilities to create user interfaces for X server, web
> browsers, or Windows presentation services? How are GUI programs currently
> being used with ScarletDME?
>

The only access to the outside world is via "qmclient". This is a C
library that allows external programs to communicate with the host. It's
very similar in function to the D3 Class Library or MVSP.

Ladybridge has made breaking changes to the wire protocol that qmclient
uses - they've introduced encryption (a good thing) and without knowing
the specifics, there's no way to make our version of the wire protocol
talk to a "modern" OpenQM system. Note that they may have made it
possible to talk to older versions of OpenQM, but I don't know.

There was also some work done with integrating qmclient with PHP, but I
don't have my notes handy on that.

When I get a chance, I'm goign to bring up the old wiki up so we can
reference it. The question here is that would it be preferrable to host
the wiki with me, or to use github's wiki facility? I tend to favor
MediaWiki, but that's just me.

[Ashley Chapman]

On 24 June 2013 15:37, Peter Walter <pete...@gmail.com> wrote:

I haven't seen anything in the documentation related to user interface features beyond the standard tty capabilities. Does ScarletDME have any native or add-on capabilities to create user interfaces for X server, web browsers, or Windows presentation services? How are GUI programs currently being used with ScarletDME?

Personally, I wrote a simple bash/CGI web interface so that I could use my own RAD web system.  This is released under the GPL, so take a look at http://billabong-services.co.uk/anji  NB, this is very much a "work in progress" release.  It is working but incomplete - I still have yet to find the time to clean up the missing bits and release them.

Ashley 

[Marshall Lucas]

QMClient also has a Java wrapper, VB Wrapper, and yes, I have seen a PHP Wrapper. The latest QMClient also allows for instantiation and calling of QMBASIC Objects.

There have been some major strides lately on OpenQM up through 3.0-8. Most notably are Exceptions (try/catch/throw) and many improvements in transactional control and system "native" multivalue functions.

It has surely come a long, long way since 2.6.x.

Marshall


Sent from Alto - altomail.com

[geneb]

On Mon, 24 Jun 2013, Peter Walter wrote:

> On 6/23/2013 5:23 PM, Ashley Chapman wrote:
>>
>> (a) OpenQM is now at 3.0-8, 11 releases ahead of ScarletDME based
>> upon OpenQM 2.6-6. Is that correct?
>>
>> Yes, but we have added some of the essential enhancements that Ladybridge
>> added to OpenQM. Generally, this "old" version is not a great problem,
>> unless you find that you have specific requirements or want to write an
>> application that takes advantage of some new feature in OpenQM. If you do
>> find this to be the case, then the source code in scarlet is fairly small
>> and simple to modify.
>
> Is there a list of the enhancements that have already been added?
>

Yes, but it's currently trapped in the old wiki. I DID get it back up
last night, but it's not reachable from outside networks.

> I was asking whether the ScarletDME project was contemplating supporting
> newer OpenQM features at some point - in other words, if it was desirable
> that (say) OpenQM 3.0-8 programs should eventually run on ScarletDME. Based
> upon your and Gene's answers, I understand the answer to be "possibly
> desired but not contemplated".
>

With the exception of a few compiler options, it's my understanding that
it remains 100% source compatible with OpenQM. Note that _binary_
compatibility was broken on purpose by Ladybridge when the GPL version was
released. You can't run OpenQM pre-compiled object files on ScarletDME or
vice-versa.

>
> BTW, I have completed reading the documentation - and I am very surprised at
> the power and capabilities of ScarletDME. A lot of the functionality I was
> contemplating adding is already in there, but I think it needs to be promoted
> better. I will be making suggestions in that direction as we move the project
> forward.
>

ScarletDME is a commercial quality MultiValue system - it's (AFAIK) 100%
feature complete with respect to the various "personalities" that it
supports. At one point I restored my full Pick D3 system (roughly 29GB)
to ScarletDME to see how it did - with the exception of code that relied
on custom assembler modes (ABS code), there were zero issues.

[Marshall Lucas]

That's one of the beautiful parts of both DME and QM. The ability to load legacy MV code from other flavors and compile a good portion right away and it works. A few small compiler directives or basic options and viola you're almost there. I've done the same thing with D3 code and UV code on QM.

[Diccon tesson]

It must be summer, you guys have woken up again. :) *Waves to all*

Peter welcome. Most of your questions would have been answered by the old wiki, very sad it died and it would serve us all well to revive it in some slightly more durable fashion. 

Gene's summary is pretty accurate. From your perspective ScarletDME is free as in beer, and free as in speech and is a hell of a lot more open to bespoking and community modification. But we aren't a busy lot and generally use and tweak it for our own clients and projects.

Current threaded comments on the alternative access/interfaces are correct. The QMClient protocol is the way of accessing Pick in a server/client fashion, from data access to subroutine calls. I've got a couple of applications that present GUI interfaces or web interfaces backing onto ScarletDME using their respective native libs (PHP and Java). Creating new API's is pretty easy as long as your language can use network ports and can handle short int's and binary manipulation.

If you want either give me a shout. They used to be hosted and documented on the wiki :P

I've also got my original reverse engineering docs for the protocol if you wanted. 

--

Diccon

--
You received this message because you are subscribed to the Google Groups "ScarletDME" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scarletdme+unsubscribe@googlegroups.com.
To post to this group, send email to scarl...@googlegroups.com.
Visit this group at http://groups.google.com/group/scarletdme.
For more options, visit https://groups.google.com/groups/opt_out.

[Peter Walter]

On 6/24/2013 11:56 AM, Diccon tesson wrote:
>
> Current threaded comments on the alternative access/interfaces are
> correct. The QMClient protocol is the way of accessing Pick in a
> server/client fashion, from data access to subroutine calls. I've got
> a couple of applications that present GUI interfaces or web interfaces
> backing onto ScarletDME using their respective native libs (PHP and
> Java). Creating new API's is pretty easy as long as your language can
> use network ports and can handle short int's and binary manipulation.
>
> If you want either give me a shout. They used to be hosted and
> documented on the wiki :P
> I've also got my original reverse engineering docs for the protocol if
> you wanted.

Diccon,

Yes - I would like the PHP & Java libraries, and the original reverse
engineering docs if you have them.

I look for ward to working with you.

Peter

[Peter Walter]

Thanks, Marshall. I hope I will have your help in getting up to speed.

Peter

[Peter Walter]

On 6/24/2013 11:14 AM, geneb wrote:

Is there a list of the enhancements that have already been added?

Yes, but it's currently trapped in the old wiki.  I DID get it back up last night, but it's not reachable from outside networks.

If ScarletDME needs a home for stuff like the wiki, I should be able to find space on one of my servers in about a month. Just let me know.

ScarletDME is a commercial quality MultiValue system - it's (AFAIK) 100% feature complete with respect to the various "personalities" that it supports.  At one point I restored my full Pick D3 system (roughly 29GB) to ScarletDME to see how it did - with the exception of code that relied on custom assembler modes (ABS code), there were zero issues.

At the risk of using up the goodwill shown to me by y'all so far, I think it is time for a bit of ranting about why I have joined this project, and the direction I hope to nudge it forward. I have been told, bluntly, that I can be rather blunt at times; I do not mean to offend, particularly as a newbie here, so I beg your forbearance if something I say ticks you off.

I am currently working on a large-scale contract project, on software that uses Universe as a base; one of the challenges of my current project is that the programming standards, where they existed, have been either ignored or weakly adhered to, requiring a lot of figuring out what the original programmer intended to do rather than what he actually did. in addition, my contract colleagues, like me, have seen a lot of sunsets, and only one programmer is under 40 years old.

I have written programs in a large variety of languages; I think in my 30+ year programming career, I have used at least twenty-five distinct languages, from assembly languages to very high-level declarative languages, and I have found the multivalue paradigm to be by far the best environment for business programming. However, multivalue languages suffer for rather archaic (and confusing) programming constructs, poor development tools, a severe shortage of younger programmers, and a lack of visibility to corporate programming environments.  What I would like to do, if ya'll agree, is to move ScarletDME in a direction that addresses all those issues, while retaining access to those features that many of us as older programmers would prefer to retain and use out of force of habit. I see two possible directions to implement my ideas in ScarletDME; one way is (a) as a higher-level abstraction of the development environment, which merely "generates" standard file structures and Basic code that will manipulate them, or (b) embedding the ideas directly in ScarletDME so that they cannot be bypassed by programmers who do not want to follow generally accepted coding standards, for whatever reason. Additionally, (c), I would like to offer a commercial version of ScarletDME - merely to address the hesitancy of many corporate environments who demand commercial support of any product they use.

How do you guys feel about these ideas?

Peter

[Peter Walter]

Ashley,

Thank you very much. I will take a close look at anji.

Peter

[geneb]

On Mon, 24 Jun 2013, Peter Walter wrote:

> On 6/24/2013 11:14 AM, geneb wrote:
>>
>>> Is there a list of the enhancements that have already been added?
>>>

>> /Yes, but it's currently trapped in the old wiki. I DID get it back up
>> last night, but it's not reachable from outside networks. /

>
> If ScarletDME needs a home for stuff like the wiki, I should be able to find
> space on one of my servers in about a month. Just let me know.
>

I can host it, that's not a problem.

> At the risk of using up the goodwill shown to me by y'all so far, I think it
> is time for a bit of ranting about why I have joined this project, and the
> direction I hope to nudge it forward. I have been told, bluntly, that I can
> be rather blunt at times; I do not mean to offend, particularly as a newbie
> here, so I beg your forbearance if something I say ticks you off.
>

We'll get along fine. I've been accused more than once of having the
subtlety of a brick to the face. :)

> environments. What I would like to do, if ya'll agree, is to move ScarletDME
> in a direction that addresses all those issues, while retaining access to
> those features that many of us as older programmers would prefer to retain
> and use out of force of habit. I see two possible directions to implement my
> ideas in ScarletDME; one way is (a) as a higher-level abstraction of the
> development environment, which merely "generates" standard file structures
> and Basic code that will manipulate them, or (b) embedding the ideas directly
> in ScarletDME so that they cannot be bypassed by programmers who do not want
> to follow generally accepted coding standards, for whatever reason.

Option abstraction layers are ok, just as long as the path exists to skip
them if the developer doesn't want it. I don't think you'll get much
traction with installing things to force a developer along a certain path.
It would be like herding cats, but cats that are not only armed, but
pissed off and looking right at YOU. :)

> Additionally, (c), I would like to offer a commercial version of ScarletDME -
> merely to address the hesitancy of many corporate environments who demand
> commercial support of any product they use.
>

You can offer commercial _support_ to ScarletDME users and you could even
sell a copy of ScarletDME to them, BUT you have to include the full,
buildable source code with it. You'd also have to include any BASIC code
that you've developed that goes with it. They would be within their
rights to build a tarball and make it available to anyone that wanted to
download it. That's the nature of the GPL. This is not a bad thing - Red
Hat has built a billion dollar business doing just that.

[Wjhonson]

Can you claify that the BASIC source code that must be included, is any BASIC source code required to make Scarlet itself work.  Not including any BASIC source code for some sort of vertical application such as running a dental office, or selling recycled car parts.

 - Get it _today_!

-- 
You received this message because you are subscribed to the Google Groups 
"ScarletDME" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to scarletdme+...@googlegroups.com.
To post to this group, send email to scarl...@googlegroups.com.
Visit this group at http://groups.google.com/group/scarletdme.
For more options, visit https://groups.google.com/groups/opt_out.

[Diccon tesson]

Peter,

:) you can Join Gene in the Blunt Pickies bar corner, there's always room. You'll find most of us still kicking about are both receptive to blunt straightforward talk and likely to dish it out...apart from Ashley who is the polite one of us ;)

If I recall from previous meeting minutes (yes we used to have those) you'll likely strike a cord with most of us here. 

* MV is a great paradigm, Check

* Suffers from lack of tools, Check ( I think each of us have tried to solve this together and independently, but it's a big job)

* Worth making available to younger programmers, Check (I am, relatively speaking, one of them at 27 and started in my teens. Attrition to more mainstream jobs has robbed us of two similarly aged developers)

Personally I've built my business on the MV coding and thinking, but while I still run both internal and clients applications on Pick (all Scarlet now) I mostly work on other environments as a commercial platform (Java, Ruby on Rails, Python, PHP, etc).

But If I see movement back here again I'll happily put some weight behind it. 

[geneb]

On Mon, 24 Jun 2013, Wjhonson wrote:

> Can you claify that the BASIC source code that must be included, is any
> BASIC source code required to make Scarlet itself work. Not including
> any BASIC source code for some sort of vertical application such as
> running a dental office, or selling recycled car parts.

If you write an application (say a medical billing package) and you ship
it with ScarletDME, you _must_ include the source code for the billing
package AND it must be licensed under the GPL.

You can sell said billing packge for elebenty billion dollars, but the
buyer is legally entitled to distribute it however they like after that
point.

If you want to develop a commercial software package that does not include
source code, you'll need to use OpenQM as the distribution mechanism.

That being said, you're perfectly within the license to charge the
customer for _support_ of that GPLed medical billing package, including
modifictions. Just understand that any modifications that you or anyone
else do to the GPL licensed application must also be licensed under the
GPL.

This would _not_ be the case had Ladybridge picked the LGPL license -
which would have been insane for them to do, because it would have
completely destroyed the commercial market for OpenQM.

If you don't intend to distribute the software, you're under no obligation
to publish anything. For example, if a dentist were to write his own
billing package with ScarletDME, he wouldn't have to publish it at all.

[Diccon tesson]

Additionally, (c), I would like to offer a commercial version of ScarletDME - merely to address the hesitancy of many corporate environments who demand commercial support of any product they use.

You can offer commercial _support_ to ScarletDME users and you could even sell a copy of ScarletDME to them, BUT you have to include the full, buildable source code with it. You'd also have to include any BASIC code that you've developed that goes with it.  They would be within their rights to build a tarball and make it available to anyone that wanted to download it.  That's the nature of the GPL.  This is not a bad thing - Red Hat has built a billion dollar business doing just that.

Easy Gene, you don't want him thinking we all wear sandals. For one thing the British weather wouldn't allow that for me ;)

Gene is right, it is GPL'd so as long a you follow the licence agreement that comes with any opens source software you can offer commercial backing however you like.

Most of us do in our own businesses.

[geneb]

On Mon, 24 Jun 2013, Diccon tesson wrote:

> Peter,
>
> :) you can Join Gene in the Blunt Pickies bar corner, there's always room.
> You'll find most of us still kicking about are both receptive to blunt
> straightforward talk and likely to dish it out...apart from Ashley who is
> the polite one of us ;)

I suspect that if Ashley got any more relaxed, his heart would stop. :)

> * Worth making available to younger programmers, Check (I am, relatively
> speaking, one of them at 27 and started in my teens. Attrition to more
> mainstream jobs has robbed us of two similarly aged developers)
>

27?! Ye gods man, you're but a child! *laughs* It's ok, we'll make you an
honorary member of The Men Who Shake Their Canes at People. :D

[Wjhonson]

What if you ship Scarlet, and then one month later *sell* a package that can run on Scarlet, but can also run on something else.

-----Original Message-----
From: geneb <ge...@deltasoft.com>
To: scarletdme <scarl...@googlegroups.com>
Sent: Mon, Jun 24, 2013 10:16 am
Subject: Re: Hello all

 - Get it _today_!

-- 
You received this message because you are subscribed to the Google Groups 
"ScarletDME" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to scarletdme+...@googlegroups.com.
To post to this group, send email to scarl...@googlegroups.com.
Visit this group at http://groups.google.com/group/scarletdme.
For more options, visit https://groups.google.com/groups/opt_out.

[Wjhonson]

Speaking of tools.
Can tools I've written and posted to the PickWiki, for example, in Pick BASIC, *run* on ScarletDME without mod?

-----Original Message-----
From: Diccon tesson <diccon...@gmail.com>
To: scarletdme <scarl...@googlegroups.com>
Sent: Mon, Jun 24, 2013 10:10 am
Subject: Re: Hello all

[geneb]

On Mon, 24 Jun 2013, Diccon tesson wrote:

> to build a tarball and make it available to anyone that wanted to download
> it. That's the nature of the GPL. This is not a bad thing - Red Hat has
> built a billion dollar business doing just that.
>
> Easy Gene, you don't want him thinking we all wear sandals. For one thing
> the British weather wouldn't allow that for me ;)

Trust me, I'm very far away from that. I just didn't want Peter to get any
misunderstandings about how things work. I had enough of that with
Martin. :)

[Peter Walter]

On 6/24/2013 10:59 AM, geneb wrote:

> When I get a chance, I'm goign to bring up the old wiki up so we can
> reference it. The question here is that would it be preferrable to
> host the wiki with me, or to use github's wiki facility? I tend to
> favor MediaWiki, but that's just me.
>
>

I am a newbie to github, so I can't speak to the desirability of hosting
it on GitHub. However, I am also a strong believer in redundancy - so I
would suggest BOTH.

Peter

[Wjhonson]

I suggest a different license for future releases.
Or a fork that specifically uses a different license :)

If Scarlet is going to grow beyond a few geeks, it can't force commercial outfits to give away source code to apps they've spent elenty billion dollars developing

-----Original Message-----
From: Diccon tesson <diccon...@gmail.com>
To: scarletdme <scarl...@googlegroups.com>
Sent: Mon, Jun 24, 2013 10:18 am
Subject: Re: Hello all

[Diccon tesson]

In my experience many Pick developers lodge the BASIC source code on site with the client for the sake of ease of fixes and further development. That automatically covers your obligation to the GPL.

Honestly the client's don't usually care, and if anything it's just a nice insurance policy if you get run over by a bus.

It does present possible challenges if you want to sell the same application un bespoked to multiple people as it opens the door for them to get a free copy...if they A) know pick B) can set up a scarletDME server ;) But honestly it's all good publicity.

The actual rules and technicality are based around "libraries". If you use any of the Scarlet libraries in your code and call them (e.g. oconv, count, dcount, etc) then your code's licence must have a "GPL compatible" licence. There are ways to isolate the issues but you'd be better off spending your time making new code than escaping a fair and reasonable licence imo.

[geneb]

On Mon, 24 Jun 2013, Wjhonson wrote:

> What if you ship Scarlet, and then one month later *sell* a package that
> can run on Scarlet, but can also run on something else.

Well anything that can run on ScarletDME should also compile and run on
OpenQM. As long as your code is compiled within ScarletDME, it inherits
the GPL license. There's nothing saying you can't t-dump your custom BP
file from Scarlet, t-load it into OpenQM and then sell binary-only
licenses. You benefit and Ladybridge does as well. Note that if your
eventual goal is to _only_ distribute commercially, you'd probably be
better off getting one of the free(?) developer licenses from Ladybridge
and do all your dev in OpenQM. That way you're sure that what you develop
on will be the same as the customer site is running.

[geneb]

On Mon, 24 Jun 2013, Wjhonson wrote:

> Speaking of tools. Can tools I've written and posted to the PickWiki,
> for example, in Pick BASIC, *run* on ScarletDME without mod?

I don't see any reason why not. I've yet to find anything that wouldn't
compile properly - you just have to make sure you've got the environment
tuned to the flavor you're starting from or you may get unexpected
flavor-dependant results.

[geneb]

On Mon, 24 Jun 2013, Peter Walter wrote:

They're totally incompatible with one another, unfortunately.

[geneb]

On Mon, 24 Jun 2013, Wjhonson wrote:

> I suggest a different license for future releases.
> Or a fork that specifically uses a different license :)
>
> If Scarlet is going to grow beyond a few geeks, it can't force
> commercial outfits to give away source code to apps they've spent elenty
> billion dollars developing

You can't do that. The only valid entity that could change how the
licensing works is Ladybridge. You can expect the heat death of the
universe to occur before that happens.

[Wjhonson]

I think there's room for interpretation in what exactly constitutes a "derivative" version of the code base.

Some people would question the assumption that anything built *using* the code base (calling it, sitting on it, sitting above it) is really a "derivative" as the GPL states.

I know you won't agree with that :)  I just suggesting that if Scarlet lives, it's going to come up at some point.

-----Original Message-----
From: geneb <ge...@deltasoft.com>

To: scarletdme <scarl...@googlegroups.com>
Sent: Mon, Jun 24, 2013 10:32 am
Subject: Re: Hello all

 - Get it _today_!

-- 
You received this message because you are subscribed to the Google Groups 
"ScarletDME" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to scarletdme+...@googlegroups.com.
To post to this group, send email to scarl...@googlegroups.com.
Visit this group at http://groups.google.com/group/scarletdme.
For more options, visit https://groups.google.com/groups/opt_out.

[Wjhonson]

Just to follow up
http://www.law.washington.edu/lta/swp/law/derivative.html

Look in particular at Example 2.1 where they tend to address the very question of apps that sit on top of some underlying work, or at least alongside them.

[Peter Walter]

All,

Wow.

I am a member of several open-source projects, from operating systems to applications; I thoroughly understand and support GPL. However, this is the first time I have ever heard of a license where if you use a GPL product such as a compiler, you have to GPL the SOURCE code. I understand GPL'ing the OBJECT code as a derivative work.

My comment about a "commercial" version of ScarletDME wasn't about CHARGING for it, but about SUPPORTING it as a commercial entity, as in the Red Hat business model. I was thinking that those of us here could start a commercial support org for ScarletDME, making it available at NO CHARGE, but charging for the SUPPORT. Without providing commercial support, no serious corporate entity will touch it as an essential part of their IT infrastructure, and it will forever be just a hobbyist application.

I think the answer is for me to actually READ the LadyBridge license  and see for myself what it allows and does not allow, informed by the legal stances of the Free Software Foundation.

Peter

You received this message because you are subscribed to a topic in the Google Groups "ScarletDME" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scarletdme/SeKdCEOChNM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scarletdme+...@googlegroups.com.

[Peter Walter]

On 6/24/2013 12:59 PM, geneb wrote:

Option abstraction layers are ok, just as long as the path exists to skip them if the developer doesn't want it.  I don't think you'll get much traction with installing things to force a developer along a certain path. It would be like herding cats, but cats that are not only armed, but pissed off and looking right at YOU. :)

Sometimes it comes down to who is armed with the heavier weapons - the customer, or the developer :-)  I am not thinking of removing *any*  functionality that developers use, merely *adding* - perhaps, more sophisticated development tools that would automate some of the tedious stuff that developers like to avoid. For example, I write most of my multivalue code using Wordpad and similar dumb text editors, but I encourage less experienced programmers to use tools that do syntax highlighting. My view is that programmers will generally use tools that improve their productivity without being coercive - but, if you want to use ED, have at it :-). Just don't complain when the other guy gets the salary raise you didn't.

Peter

[Peter Walter]

On 6/24/2013 1:18 PM, Diccon tesson wrote:

Easy Gene, you don't want him thinking we all wear sandals. For one thing the British weather wouldn't allow that for me ;)

For the record, I do wear sandals - and on the beach, too. My Jamaican weather allows that. :-)

Peter

[Peter Walter]

On 6/24/2013 1:30 PM, geneb wrote:
> I am a newbie to github, so I can't speak to the desirability of
> hosting it on GitHub. However, I am also a strong believer in
> redundancy - so I would suggest BOTH.
>>
> They're totally incompatible with one another, unfortunately.

Then, I vote for MediaWiki. While GitHub is unlikely to go away, one can
never be sure.

Peter

[Ashley Chapman]

On 24 June 2013 19:03, Peter Walter <pete...@gmail.com> wrote:

All,

Wow.

I am a member of several open-source projects, from operating systems to applications; I thoroughly understand and support GPL. However, this is the first time I have ever heard of a license where if you use a GPL product such as a compiler, you have to GPL the SOURCE code. I understand GPL'ing the OBJECT code as a derivative work.

I would be VERY interested in what conclusions you come to here!  Ladybridge have their own interpretation of their licence, which is that all aplications that use the GPL Openqm (or ScarletDME), also inherit the GPL, so can only be released with source.  I'm not convinced myself, as they use the GPL2 licence, and didn't add any conditions to it in the source code release.
 

My comment about a "commercial" version of ScarletDME wasn't about CHARGING for it, but about SUPPORTING it as a commercial entity, as in the Red Hat business model. I was thinking that those of us here could start a commercial support org for ScarletDME, making it available at NO CHARGE, but charging for the SUPPORT. Without providing commercial support, no serious corporate entity will touch it as an essential part of their IT infrastructure, and it will forever be just a hobbyist application.

 

Good plan.
 

I think the answer is for me to actually READ the LadyBridge license  and see for myself what it allows and does not allow, informed by the legal stances of the Free Software Foundation.

 

Another good plan!

Ashley 

[geneb]

On Mon, 24 Jun 2013, Peter Walter wrote:

> My comment about a "commercial" version of ScarletDME wasn't about CHARGING
> for it, but about SUPPORTING it as a commercial entity, as in the Red Hat
> business model. I was thinking that those of us here could start a commercial
> support org for ScarletDME, making it available at NO CHARGE, but charging
> for the SUPPORT. Without providing commercial support, no serious corporate
> entity will touch it as an essential part of their IT infrastructure, and it
> will forever be just a hobbyist application.
>

There's nothing preventing the creation of a commercial support structure
for ScarletDME. The interpretation here is that because the GPL covers
the compiler in ScarletDME, it's output would be considered a derivative
work, and thus GPL licensed as well.

> I think the answer is for me to actually READ the LadyBridge license and see
> for myself what it allows and does not allow, informed by the legal stances
> of the Free Software Foundation.

AFAIK, there is no "LadyBridge license". It's GPLv2.

[geneb]

On Mon, 24 Jun 2013, Peter Walter wrote:

> On 6/24/2013 12:59 PM, geneb wrote:
>

> /Option abstraction layers are ok, just as long as the path exists to skip

> them if the developer doesn't want it. I don't think you'll get much
> traction with installing things to force a developer along a certain path. It
> would be like herding cats, but cats that are not only armed, but pissed off

> and looking right at YOU. :) //
> /

> Sometimes it comes down to who is armed with the heavier weapons - the
> customer, or the developer :-) I am not thinking of removing *any*
> functionality that developers use, merely *adding* - perhaps, more
> sophisticated development tools that would automate some of the tedious stuff
> that developers like to avoid. For example, I write most of my multivalue
> code using Wordpad and similar dumb text editors, but I encourage less
> experienced programmers to use tools that do syntax highlighting. My view is
> that programmers will generally use tools that improve their productivity
> without being coercive - but, if you want to use ED, have at it :-). Just
> don't complain when the other guy gets the salary raise you didn't.
>

You can do that fairly easily - just today a guy posted a config file for
the editor "nano" that would syntax highlight BASIC code. One of the wiki
entries covers how to use external editors if you don't like SED or ED.
Note that AccuTerm supports ScarletDME as well (through their OpenQM
code).

[geneb]

On Mon, 24 Jun 2013, Ashley Chapman wrote:

>
> I would be VERY interested in what conclusions you come to here!
> Ladybridge have their own interpretation of their licence, which is that
> all aplications that use the GPL Openqm (or ScarletDME), also inherit the
> GPL, so can only be released with source. I'm not convinced myself, as
> they use the GPL2 licence, and didn't add any conditions to it in the
> source code release.
>

AFAIK, no changes CAN be made to the GPL. It's an all or nothing thing.
You can be granted more rights than the GPL conveys, but not fewer.

I look at it like this - if I write some code under ScarletDME, compile it
and send you the binaries, then the code & binaries are covered under the
GPL. If I write the code under Scarlet and compile the code for release
on the commercial release of OpenQM, then it's NOT covered by the GPL.

[Marcus Rhodes]

And I'm working one for gedit/pluma.

(I'm a Mint/Mate user now that KDE, Gnome, and even Ubuntu have gone to the dark side.)

(That ought to provoke some discussion, eh?)

By the way, all you *n*x users out there discussing tools and such.  Try injecting a bit of Zenity or KDialog (or just plain old dialog) to lace your programs with a bit of GUI (or CUI) that your users are sure to love.

Zenity can even be installed on Windows now.  If the links are down, I have the installer somewhere.

-----Original Message-----
From: geneb <ge...@deltasoft.com>

[Wjhonson]

As a ten-year Wikipedian, I would vote for a MediaWiki install as well.
I already know how to use it.

-----Original Message-----
From: Peter Walter <pete...@gmail.com>
To: scarletdme <scarl...@googlegroups.com>
Cc: geneb <ge...@deltasoft.com>
Sent: Mon, Jun 24, 2013 11:22 am
Subject: Re: Hello all

On 6/24/2013 1:30 PM, geneb wrote:
> I am a newbie to github, so I can't speak to the desirability of 
> hosting it on GitHub. However, I am also a strong believer in 
> redundancy - so I would suggest BOTH.
>>
> They're totally incompatible with one another, unfortunately.

Then, I vote for MediaWiki. While GitHub is unlikely to go away, one can 
never be sure.

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"ScarletDME" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to scarletdme+...@googlegroups.com.
To post to this group, send email to scarl...@googlegroups.com.
Visit this group at http://groups.google.com/group/scarletdme.
For more options, visit https://groups.google.com/groups/opt_out.

[Wjhonson]

But the source code isn't output.

-----Original Message-----
From: geneb <ge...@deltasoft.com>
To: scarletdme <scarl...@googlegroups.com>
Sent: Mon, Jun 24, 2013 11:50 am
Subject: Re: Hello all

 - Get it _today_!

-- 
You received this message because you are subscribed to the Google Groups 
"ScarletDME" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to scarletdme+...@googlegroups.com.
To post to this group, send email to scarl...@googlegroups.com.
Visit this group at http://groups.google.com/group/scarletdme.
For more options, visit https://groups.google.com/groups/opt_out.

[Tom Potts]

Just to clarify a little, the problem is not the compiler, per se; the GPL is very clear that the output of a GPL'd compiler is not automatically covered by the GPL (hence why GCC can be used without restriction). The issue comes with linking. Because the code cannot be used in any way without reference to the Scarlet opcodes, it means that the code is linked to the Scarlet runtime, and linking makes it a derivative work.

If you're scratching your head and thinking "surely that means all programs for Linux are covered by the GPL", you'd be right. Linus has stated that he doesn't consider compiling in this way to be linking, but strictly speaking, it is. Linus won't get litigious about it, however; Ladybridge might.

Tom

P.S. Yes, I'm still here! Mostly lurking, but I did a fair bit of research about this some time ago, so I thought I'd pipe up. :-)

[Ashley Chapman]

On 24 June 2013 23:16, Tom Potts <kara...@gmail.com> wrote:

Just to clarify a little, the problem is not the compiler, per se; the GPL is very clear that the output of a GPL'd compiler is not automatically covered by the GPL (hence why GCC can be used without restriction). The issue comes with linking. Because the code cannot be used in any way without reference to the Scarlet opcodes, it means that the code is linked to the Scarlet runtime, and linking makes it a derivative work.

If you're scratching your head and thinking "surely that means all programs for Linux are covered by the GPL", you'd be right. Linus has stated that he doesn't consider compiling in this way to be linking, but strictly speaking, it is. Linus won't get litigious about it, however; Ladybridge might.

Tom

P.S. Yes, I'm still here! Mostly lurking, but I did a fair bit of research about this some time ago, so I thought I'd pipe up. :-)

Thanks Tom, that's a great help.

I guess it's one of those grey areas so loved by lawyers!  Do you have any references from when you did your research?
 

[Wjhonson]

So you're still excluding the source code, which was the main bone of contention in my mind.

[Diccon tesson]

Big upvote for gedit syntax hilighter.
Use gedit + fuse mounting for most of my development environments... Bar java and netbeans :p

Really need to write that fuse-scarlet lib at some point we discussed ages ago Tom.
Remote file like editing of pick for the win :)

[geneb]

On Mon, 24 Jun 2013, Tom Potts wrote:

> Just to clarify a little, the problem is not the compiler, per se; the GPL
> is very clear that the output of a GPL'd compiler is not automatically
> covered by the GPL (hence why GCC can be used without restriction). The
> issue comes with linking. Because the code cannot be used in any way
> without reference to the Scarlet opcodes, it means that the code is linked
> to the Scarlet runtime, and linking makes it a derivative work.
>
> If you're scratching your head and thinking "surely that means all programs
> for Linux are covered by the GPL", you'd be right. Linus has stated that he
> doesn't consider compiling in this way to be linking, but strictly
> speaking, it is. Linus won't get litigious about it, however; Ladybridge
> might.
>

Thanks for the info Tom! Nice to see you're still lurking. :)

[Ashley Chapman]

On 25 June 2013 00:26, Wjhonson <wjho...@aol.com> wrote:

So you're still excluding the source code, which was the main bone of contention in my mind.

When you "compile" a programme with Scarlet, you're creating a new file of opcodes.  At some later point (after distribution), this is then run by the Scarlet run-machine.  There is no "linking" of your programme, but there is execution by the run-machine.  There is no way that anybody can think of this as a derived work, but my opinion is not what counts.  Legal judgements are what count.

I did find reference to a case of a CAD package (can't recall it's name)  that used it's own propriatory storage format, where the vendor claimed that the end-user could not make a new programme to read the storage file, as that would then be a derived work.  They lost in court bigtime.  Just as well, or we would not have any programmes like OpenOffice which can read Microsoft's proprietary document format.

This discussion comes up periodically, and seems to scare newcomers away.  Would be good to finally draw a conclusion to it that is based upon case law, rather than peoples opinions.

Ashley

[Peter Walter]

I remember a legal case 30+ years ago in which IBM sued an application vendor, claiming that the vendor breached copyright by providing non-IBM-approved application software to IBM clients. The core of IBM's argument was that the object code provided used IBM's proprietary System/360 instruction set, and therefore breached copyright. The court eventually ruled that the vendor couldn't distribute the object code without IBM's permission, a sort of victory for IBM, but the court also ruled that merely providing SOURCE code that compiled under IBM's compilers did NOT violate copyright, which was a bigger victory for the vendor. The vendor went on to provide their application in source-code-only format, which was then compiled by the customer, as was the practice anyway in those days; and that decision opened the door to competition in the highly closed and extremely lucrative market for IBM mainframe application and operating system software - as long as it wasn't supplied in compiled form.

I don't think that providing source code to a customer, then having the CUSTOMER compile and run it, breaks the GPL, as long as the CUSTOMER or vendor does not distribute the resulting object code. Providing software in this way is still a mainstay in the mainframe world, and is the primary reason software is LICENSED, not SOLD.

However, as Ashley says, what matters is the legal judgments, not anecdotal stories like mine, and I am not a lawyer. I have contacted the Free Software Foundation, and the GROKLAW intellectual property site, to try to get a (non-binding) opinion from them on this matter without calling any names. If they think selling the RIGHT to compile and use the source code on a GPL'ed ScarletDME does not break GPL, then I wouldn't worry about what LadyBridge thinks; the FSF has committed to defending / prosecuting alleged breaches of the GPL, and would defend us as long as we have our ducks in a row.

Having said all of that, I don't want to cause any hard feelings within this close-knit group by proceeding in a direction unsupported by some of the members; I could merely fork the project (again) for a commercial version if y'all would prefer that I do that, rather than use ScarletDME or OpenQM directly.

Please let me know what you think.

Peter

[Diccon tesson]

Nah, stay where you are Peter. Your among friends. It's just our founding gripe with the original OpenQM (Which ironically isn't open at all any more) and one we never definitively escaped from the legal binding to Ladybridge despite all of us really researching the specific application of the GPL in this case. Although there are several "work arounds" including GPL compatible wrappers and nesting your proprietary code behind the network stack (ie use the LGPL API's). 

If you want to provide a commercial support structure or group for the open source Scarlet DME you have my support.

In practice I'd always intended to run my business on and written in open source software anyway, just in the birthing period it's nice to have the protection of telling competing software houses they can't see your private secrets. It's only really immoral competitors you need to worry about in this scenario. Clients don't care about becoming software houses, and they generally pay you for helping them keep going. If they don't walk away, find another.

The biggest issue is that Pick in general has an older fraternity of developers who are used to nice simple "it's mine you can't have it" protected software licencing laws. In practice we all just need to adapt to the idea we're being paid to write code, not sit back and sell copies of the same stuff. Ironically most Pick developers write bespoke programs anyway which wouldn't be amazingly useful except to the targeted user(s). There the most suited to a open source business model.

Look at what happens in the web fraternity. You have a job where you need to attach files to products on a website. You find there aren't very good tools for doing so, you write some that are easy to use and work well. You open source them because you think it works well, you've been paid by your client and they are happy. 100 people use your code/program, 3 of them offer you work to enhance the product or build something similar because they really like what you did. You keep drinking mojitos. 

</rant>

--

[geneb]

On Tue, 25 Jun 2013, Peter Walter wrote:

> Having said all of that, I don't want to cause any hard feelings within this
> close-knit group by proceeding in a direction unsupported by some of the
> members; I could merely fork the project (again) for a commercial version if
> y'all would prefer that I do that, rather than use ScarletDME or OpenQM
> directly.
>

I don't think you'll have any disagreement(sp!) with anyone here.
However, you'll need to forgive me if I lay in a few cases of popcorn when
Ladybridge gets wind of it. :)

[geneb]

On Tue, 25 Jun 2013, Diccon tesson wrote:

> If you want to provide a commercial support structure or group for the open
> source Scarlet DME you have my support.
>

Seconded. (but I repeat myself. :D )

> The biggest issue is that Pick in general has an older fraternity of
> developers who are used to nice simple "it's mine you can't have it"
> protected software licencing laws. In practice we all just need to adapt to
> the idea we're being paid to write code, not sit back and sell copies of

THIS! A MILLION TIMES, THIS! :)

What I'd really like to see is something that would bring new blood into
our little multi-value universe. Something that reminds all the "nosql"
folks that our flavor of nosql was around before they were born, and it
still kicks ass. :)

How cool would it be to have a fork of MediaWiki that used ScarletDME as
the back end? No more worries about XSS or SQL injection attacks, etc.

[Peter Walter]

On 6/25/2013 9:33 AM, geneb wrote:
>
> What I'd really like to see is something that would bring new blood
> into our little multi-value universe. Something that reminds all the
> "nosql" folks that our flavor of nosql was around before they were
> born, and it still kicks ass. :)

+10^6 Exactly. I employ young programmers; they look at the multivalue
Universe (pun intended) and grimace. Of course, they love it once they
actually write something useful ... I would like to add features to
ScarletDME that the young 'uns think is essential to their environments.
Many of the features require lower-level building blocks to be available
first.

With that in mind, I'd like to ask about / discuss / suggest some
features for a future version of ScarletDME. I really like the object
support in ScarletDME - that would have been one of my primary requests
if it wasn't already a feature. A couple of other things I would like to
have, for starters:

(a) In a multivalue implementation I have worked with, a "private"
implementation for a company, the compiler came in two versions; a
"system" compiler, accessible to SYSPROG only, and a regular compiler,
accessible to regular programmers. The difference between the two is
that the system compiler can compile statements that would be treated as
errors with the regular compiler, such as statements that modify
/SYSCOM/ variables that are normally read-only, and statements that
accessed low-level features of the OS, such as devices. The system
compiler was written in the same Basic language, and further used to
compile itself and the regular compiler. The advantage of using such a
compiler is that the work of extending the language with new features
can then be shared between the low-level C, C++ or ASM programmers, and
with Basic programmers authorized to use / aliased to the SYSPROG account.

(b) HTML5 is rapidly becoming a major user interface of choice.
Multivalue products generally support only simple text interfaces,
unless an interfacing stack is used, such as
html<-->php<-->c-interface<-->mymvproduct. Young programmers would be
attracted to ScarletDME if we provided a server-side scripting interface
which would allow ScarletDME Basic to be directly embedded in web pages,
in the same manner as PHP and other scripting languages.

(c) While HTML is great for web-oriented programs, for many programs, a
desktop GUI metaphor works a lot better. If ScarletDME supported a few
graphics primitives and better event queues, library routines could be
developed which could display and use the usual GUI controls. My model
for such functionality is GFA-Basic
(http://en.wikipedia.org/wiki/GFA_BASIC), one of the languages I have
used to develop programs in the past. If we used a cross-platform
environment target such as Qt
(http://en.wikipedia.org/wiki/Qt_%28framework%29), we could target
Windows, X, and smartphone interfaces all at once.

Please let me know what you think about the above as features for a
future version of ScarletDME.

Peter

[geneb]

On Tue, 25 Jun 2013, Peter Walter wrote:

> (a) In a multivalue implementation I have worked with, a "private"
> implementation for a company, the compiler came in two versions; a "system"
> compiler, accessible to SYSPROG only, and a regular compiler, accessible to
> regular programmers. The difference between the two is that the system
> compiler can compile statements that would be treated as errors with the
> regular compiler, such as statements that modify /SYSCOM/ variables that are
> normally read-only, and statements that accessed low-level features of the
> OS, such as devices. The system compiler was written in the same Basic
> language, and further used to compile itself and the regular compiler. The
> advantage of using such a compiler is that the work of extending the language
> with new features can then be shared between the low-level C, C++ or ASM
> programmers, and with Basic programmers authorized to use / aliased to the
> SYSPROG account.
>

That smells a LOT like Advanced Revelation. :) I'm not sure that brings
much to the table though. I can't think of a compelling reason to block
language features like that. It's like patching the software to fix a
hardware problem - it's probably better to fix the hardware (the
programmer doing bad things) than it is to put training wheels on the
system.

> (b) HTML5 is rapidly becoming a major user interface of choice. Multivalue
> products generally support only simple text interfaces, unless an interfacing
> stack is used, such as html<-->php<-->c-interface<-->mymvproduct. Young
> programmers would be attracted to ScarletDME if we provided a server-side
> scripting interface which would allow ScarletDME Basic to be directly
> embedded in web pages, in the same manner as PHP and other scripting
> languages.
>

I don't know if you're familiar with D3 at all, but it has what are called
"rule modules". They're essentially basic subroutines that are called
outside of D3 - I use them extensively in my .Net & ASP.Net apps. Is this
the kind of thing you're talking about?

> (c) While HTML is great for web-oriented programs, for many programs, a
> desktop GUI metaphor works a lot better. If ScarletDME supported a few
> graphics primitives and better event queues, library routines could be
> developed which could display and use the usual GUI controls. My model for
> such functionality is GFA-Basic (http://en.wikipedia.org/wiki/GFA_BASIC), one
> of the languages I have used to develop programs in the past. If we used a
> cross-platform environment target such as Qt
> (http://en.wikipedia.org/wiki/Qt_%28framework%29), we could target Windows,
> X, and smartphone interfaces all at once.
>

For desktop applications, this is a solved problem - AccuTerm has a
full-featured GUI environment that operates seamlessly with just about
every MV platform on the planet. It IS per-seat/site licensed though.
If you're familiar with AccuTerm, are you proposing an open source
alternative?

[Peter Walter]

On 6/25/2013 10:43 AM, geneb wrote:
>
> That smells a LOT like Advanced Revelation. :) I'm not sure that
> brings much to the table though. I can't think of a compelling reason
> to block language features like that. It's like patching the software
> to fix a hardware problem - it's probably better to fix the hardware
> (the programmer doing bad things) than it is to put training wheels on
> the system.

The private implementation wasn't AREV, but was a lot like AREV with
extended features. The reason for the dual mode of the compiler was more
in the model of the dichotomy between the *nix root user and all other
users - access to certain dangerous features was restricted to trusted
programmers, and the dangerous code was encapsulated in functions and
subroutines a regular programmer couldn't screw with. Yes, it is better
to fix the programmer, but that event generally happens *after* the
disaster. Prohibiting access prevents the disaster.

>
> I don't know if you're familiar with D3 at all, but it has what are
> called "rule modules". They're essentially basic subroutines that are
> called outside of D3 - I use them extensively in my .Net & ASP.Net
> apps. Is this the kind of thing you're talking about?

With HTML programming, I stick to the LAMP stack and only rarely venture
into ASP.NET. I assume you are talking about rule modules as discussed
in
(http://dbaspot.com/pick-database/338470-vb-net-brcall-rule-module-d3-using-odbc.html).
That isn't quite what I am talking about - more like this html/php snippet:

html>
<title>HTML with PHP</title>
<body>
<h1>My Example</h1>

<?php
echo "Hello, $you";
?>
</body>
</html>

With ScarletDME, it would look like:

html>
<title>HTML with ScarletDME</title>
<body>
<h1>My Example</h1>

<?sdme
PRINT "Hello, @WHO";
?>
</body>
</html>

>
> For desktop applications, this is a solved problem - AccuTerm has a
> full-featured GUI environment that operates seamlessly with just about
> every MV platform on the planet. It IS per-seat/site licensed though.
> If you're familiar with AccuTerm, are you proposing an open source
> alternative?

AccuTerm's desktop GUI interface only runs under IE, and is really
"middleware" meant to transition green-screen programs with a minimum of
effort. I want to run a ScarletDME GUI natively on
Linux/Windows/Android/IPhone/whatever using only open-source
technologies, and build my own desktop widgets. Allowing ScarletDME
programs to access Qt library functions would facilitate building
full-feature, rich interfaces without licensing third-party code.

Peter

[geneb]

On Tue, 25 Jun 2013, Peter Walter wrote:

> The private implementation wasn't AREV, but was a lot like AREV with extended
> features. The reason for the dual mode of the compiler was more in the model
> of the dichotomy between the *nix root user and all other users - access to
> certain dangerous features was restricted to trusted programmers, and the
> dangerous code was encapsulated in functions and subroutines a regular
> programmer couldn't screw with. Yes, it is better to fix the programmer, but
> that event generally happens *after* the disaster. Prohibiting access
> prevents the disaster.
>

It's not my cup of tea and as long as the feature is disabled by default,
I don't have any issue with it being present.

> With ScarletDME, it would look like:
>
> html>
> <title>HTML with ScarletDME</title>
> <body>
> <h1>My Example</h1>
>
> <?sdme
> PRINT "Hello, @WHO";
> ?>
> </body>
> </html>
>

I can see that path being very, very problematic unless you're using
ScarletDME _as_ the webserver (which has been done).

You might be more interested in this:
http://scarlet.deltasoft.com/index.php/PHP_Native_API

Diccon, if you've got a current copy of the API, please tar it up and
email it to me and I'll get it in the repository, otherwise I'll have to
pull it from SVN tonight.

I think it would be a far better thing to have a feature complete API into
ScarletDME over trying to make it do things that the architecture(sp!)
wasn't designed for.

> AccuTerm's desktop GUI interface only runs under IE, and is really
> "middleware" meant to transition green-screen programs with a minimum of
> effort. I want to run a ScarletDME GUI natively on
> Linux/Windows/Android/IPhone/whatever using only open-source technologies,
> and build my own desktop widgets. Allowing ScarletDME programs to access Qt
> library functions would facilitate building full-feature, rich interfaces
> without licensing third-party code.

Ah, we're talking past each other. :) When I think "AccuTerm", I think
the terminal emulator, not the browser based side of it.

The case you list above is another example of why having a good API would
be of benefit in the long run. The wire protocol is pretty simple, so
there's no reason we couldn't have multiple native language
implementations of the API. Java, Python, Ruby, .Net, etc. should be very
simple to implement.

[Peter Walter]

On 6/25/2013 12:03 PM, geneb wrote:

On Tue, 25 Jun 2013, Peter Walter wrote:

The private implementation wasn't AREV, but was a lot like AREV with extended features. The reason for the dual mode of the compiler was more in the model of the dichotomy between the *nix root user and all other users - access to certain dangerous features was restricted to trusted programmers, and the dangerous code was encapsulated in functions and subroutines a regular programmer couldn't screw with.  Yes, it is better to fix the programmer, but that event generally happens *after* the disaster. Prohibiting access prevents the disaster.

It's not my cup of tea and as long as the feature is disabled by default, I don't have any issue with it being present.

Ok.

With ScarletDME, it would look like:

.....

I can see that path being very, very problematic unless you're using ScarletDME _as_ the webserver (which has been done).

In a sense, yes. The way PHP and other scripting languages work with Apache and similar web servers is that once the html parser in the web server detects the opening "<?xxx" tag, the html parser parses the text between the <?xxx and ?> tags, and passes it to the target interpreter; the target interpreter executes the code, and returns whatever output to the web server parser. This method is now the preferred method of interfacing external semi-compiled and interpreted languages with  Apache and work-alike servers. It is also used with IIS.

I think it would be a far better thing to have a feature complete API into ScarletDME over trying to make it do things that the architecture(sp!) wasn't designed for.

I understand and appreciate that viewpoint. However, I argue that using the PHP Native API interposes two unnecessary layers of complexity; PHP, and the C interface for the API. It isn't that difficult to allow the web server  to talk directly with ScarletDME, reducing the complexity of the connection, and the code embedding facilitates programmer productivity if you work a lot with the html UI.

Ah, we're talking past each other. :)  When I think "AccuTerm", I think the terminal emulator, not the browser based side of it.

The terminal emulator is exactly that - an emulator, not a native implementation, and is irrelevant and unnecessary on environments such as smartphones.

The case you list above is another example of why having a good API would be of benefit in the long run. The wire protocol is pretty simple, so there's no reason we couldn't have multiple native language implementations of the API.  Java, Python, Ruby, .Net, etc. should be very simple to implement.

I don't have any problem with the multiple API implementations, for those who will use them. What I am proposing is merely additional APIs and features alongside whatever others exist. I am not suggesting removing anything. The additional features I suggest would be of interest to younger programmers used to similar features in other environments.

Peter

[Ashley Chapman]

On 25 June 2013 16:26, Peter Walter <pete...@gmail.com> wrote:

On 6/25/2013 10:43 AM, geneb wrote:

That smells a LOT like Advanced Revelation. :)  I'm not sure that brings much to the table though.  I can't think of a compelling reason to block language features like that.  It's like patching the software to fix a hardware problem - it's probably better to fix the hardware (the programmer doing bad things) than it is to put training wheels on the system.

The private implementation wasn't AREV, but was a lot like AREV with extended features. The reason for the dual mode of the compiler was more in the model of the dichotomy between the *nix root user and all other users - access to certain dangerous features was restricted to trusted programmers, and the dangerous code was encapsulated in functions and subroutines a regular programmer couldn't screw with.  Yes, it is better to fix the programmer, but that event generally happens *after* the disaster. Prohibiting access prevents the disaster.

These is already an "internal" mode of the compiler.  Accessible by starting Scarlet with an -i argument.  It then allows use of some core functionality

EG:-
$internal ;*                                     Doesn't work, without -i option on command
$define evt$unload 4 ;*                          CLEAR OUT PROGRAM CACHE, IN CASE OF PROGRAM RECOMPILE
resp = events(-1, evt$unload)


 

Ashley

[Peter Walter]

On 6/25/2013 12:30 PM, Ashley Chapman wrote:
>
> These is already an "internal" mode of the compiler. Accessible by
> starting Scarlet with an -i argument. It then allows use of some core
> functionality

Great. Scarlet is even more awesome than I thought.

Peter

[Wjhonson]

"terminal emulation is now available for iPhone"

.....

Good old songs never die, they just get recycled

-----Original Message-----
From: Peter Walter <pete...@gmail.com>
To: scarletdme <scarl...@googlegroups.com>
Cc: geneb <ge...@deltasoft.com>

Sent: Tue, Jun 25, 2013 9:29 am
Subject: Re: Hello all

[geneb]

On Tue, 25 Jun 2013, Peter Walter wrote:

> In a sense, yes. The way PHP and other scripting languages work with Apache
> and similar web servers is that once the html parser in the web server
> detects the opening "<?xxx" tag, the html parser parses the text between the
> <?xxx and ?> tags, and passes it to the target interpreter; the target
> interpreter executes the code, and returns whatever output to the web server
> parser. This method is now the preferred method of interfacing external
> semi-compiled and interpreted languages with Apache and work-alike servers.
> It is also used with IIS.

Can you point me to where this method is described in detail? It would be
interesting beyond belief to pull this kind of thing off. Minds would be
blown and sneering geeks around the world would take up the "BASIC sucks!"
mantra again. :) (and then quietly sob when it proves to be performant
and insanely exploit-proof right out of the box)


>>
>>
>> /I think it would be a far better thing to have a feature complete API into

>> ScarletDME over trying to make it do things that the architecture(sp!)

>> wasn't designed for. /

>
> I understand and appreciate that viewpoint. However, I argue that using the
> PHP Native API interposes two unnecessary layers of complexity; PHP, and the
> C interface for the API. It isn't that difficult to allow the web server to
> talk directly with ScarletDME, reducing the complexity of the connection, and
> the code embedding facilitates programmer productivity if you work a lot with
> the html UI.

The PHP interface that Diccon put together is 100% PHP - there's no C
binding to it.

I've gotten it online (my wife bumped a machine for me) here:
http://github.com/geneb/PHPQMClient

[geneb]

On Tue, 25 Jun 2013, Ashley Chapman wrote:

>>
> These is already an "internal" mode of the compiler. Accessible by
> starting Scarlet with an -i argument. It then allows use of some core
> functionality
>
> EG:-
> $internal ;* Doesn't work, without -i
> option on command
> $define evt$unload 4 ;* CLEAR OUT PROGRAM CACHE,
> IN CASE OF PROGRAM RECOMPILE
> resp = events(-1, evt$unload)
>
>

Thanks Ashley, I'd completely forgotten about that - it's actually
required in order to rebuild the BASIC compiler with the BASIC compiler.
:)

[Wjhonson]

Your wife has the power to make things work by touch?
Can I borrow her for a week or so?

-----Original Message-----
From: geneb <ge...@deltasoft.com>
To: scarletdme <scarl...@googlegroups.com>
Sent: Tue, Jun 25, 2013 9:37 am
Subject: Re: Hello all

 - Get it _today_!

-- 
You received this message because you are subscribed to the Google Groups 
"ScarletDME" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to scarletdme+...@googlegroups.com.
To post to this group, send email to scarl...@googlegroups.com.
Visit this group at http://groups.google.com/group/scarletdme.
For more options, visit https://groups.google.com/groups/opt_out.

[geneb]

On Tue, 25 Jun 2013, Wjhonson wrote:

> Your wife has the power to make things work by touch?
> Can I borrow her for a week or so?
>

NO! :)

[Ashley Chapman]

In a sense, yes. The way PHP and other scripting languages work with Apache and similar web servers is that once the html parser in the web server detects the opening "<?xxx" tag, the html parser parses the text between the <?xxx and ?> tags, and passes it to the target interpreter; the target interpreter executes the code, and returns whatever output to the web server parser. This method is now the preferred method of interfacing external semi-compiled and interpreted languages with  Apache and work-alike servers. It is also used with IIS.

This would be brilliant.  I had thought this for a long time, but thought that it would be just too hard to achieve with Scarlet.  One particular area that concerns me is that if there was BASIC inside the tags, it would have to be compiled (JIT like) for each page request.  Unless we do something clever like Zend did with their PHP engine.

Ashley

[Peter Walter]

On 6/25/2013 12:36 PM, geneb wrote:
>
> Can you point me to where this method is described in detail? It
> would be interesting beyond belief to pull this kind of thing off.
> Minds would be blown and sneering geeks around the world would take up
> the "BASIC sucks!" mantra again. :) (and then quietly sob when it
> proves to be performant and insanely exploit-proof right out of the box)

http://www.apacheweek.com/features/dynamicpages

>
> The PHP interface that Diccon put together is 100% PHP - there's no C
> binding to it.
>
> I've gotten it online (my wife bumped a machine for me) here:
> http://github.com/geneb/PHPQMClient

Thank you very much. I plan to use it until we get ScarletDME interfaced
to Apache via an apache module.

Peter

[Peter Walter]

On 6/25/2013 12:39 PM, geneb wrote:
> NO! :)

Blast it. I was about to join the queue behind wjohnson. :-)

Peter

[Peter Walter]

On 6/25/2013 12:49 PM, Ashley Chapman wrote:
>
> This would be brilliant. I had thought this for a long time, but
> thought that it would be just too hard to achieve with Scarlet. One
> particular area that concerns me is that if there was BASIC inside the
> tags, it would have to be compiled (JIT like) for each page request.
> Unless we do something clever like Zend did with their PHP engine.

It is not that difficult. (1) ensure that your compiler can compile an
input string to an output (object) string; (2) when the web parser sends
you code, compute the SHA1 of the code; look in a cache to see if you
already have a matching compiled version; if not, compile and cache it;
load and execute the compiled code. (3) delete the cache when the web
server restarts.

There is a short delay the first time the code fragment is compiled;
after that, the code runs at full speed.

Peter

[geneb]

On Tue, 25 Jun 2013, Peter Walter wrote:

> On 6/25/2013 12:36 PM, geneb wrote:
>>
>> Can you point me to where this method is described in detail? It would be
>> interesting beyond belief to pull this kind of thing off. Minds would be
>> blown and sneering geeks around the world would take up the "BASIC sucks!"
>> mantra again. :) (and then quietly sob when it proves to be performant and
>> insanely exploit-proof right out of the box)
>
> http://www.apacheweek.com/features/dynamicpages
>

Pondering...

If it did:

<?sdme
CUSTOMER:WEB.BP:FANCY.FUNCTION
- lots of code -
?>

The first line points to account, BP file and filename of the function.
If this is the first time we've seen this function, save it to WEB.BP in
the CUSTOMER account as FANCY.FUNCTION. If it's already present, check
CRC of what got pulled from the <?sdme ?> block against the source code in
WEB.BP - if they differ, recompile.
Execute code...

Sane idea?

[geneb]

On Tue, 25 Jun 2013, Peter Walter wrote:

> On 6/25/2013 12:49 PM, Ashley Chapman wrote:
>>
>> This would be brilliant. I had thought this for a long time, but thought
>> that it would be just too hard to achieve with Scarlet. One particular
>> area that concerns me is that if there was BASIC inside the tags, it would
>> have to be compiled (JIT like) for each page request. Unless we do
>> something clever like Zend did with their PHP engine.
>
> It is not that difficult. (1) ensure that your compiler can compile an input
> string to an output (object) string; (2) when the web parser sends you code,
> compute the SHA1 of the code; look in a cache to see if you already have a
> matching compiled version; if not, compile and cache it; load and execute the
> compiled code. (3) delete the cache when the web server restarts.
>

Just about the same thing I thought up. :)

I'd rather see the apache module doing it the way I suggested in order to
keep from trying to pass potentially huge command lines to the system.

Were you thinking something along the lines of :

sdme_exec /path/to/temp-file

With output going to stdout?

[Peter Walter]

On 6/25/2013 1:08 PM, geneb wrote:
>
> If it did:
>
> <?sdme
> CUSTOMER:WEB.BP:FANCY.FUNCTION
> - lots of code -
> ?>
>
> The first line points to account, BP file and filename of the function.
> If this is the first time we've seen this function, save it to WEB.BP
> in the CUSTOMER account as FANCY.FUNCTION. If it's already present,
> check CRC of what got pulled from the <?sdme ?> block against the
> source code in WEB.BP - if they differ, recompile.
> Execute code...
>
> Sane idea?

Nearly. You don't need the first line like that. Consider:

<?sdme
IF @WHO = "APACHE" THEN
RESULT = FANCY.FUNCTION(@WHO)
@ANS = RESULT[-3,3]
END
?>
Where FANCY.FUNCTION is cataloged as normal. Take the whole block of
code and calculate the CRC, check against WEBCACHE.BP, etc ... just
execute the fragment as if it had been loaded like an I-descriptor. in
fact, it would look pretty much like the code in an I-descriptor.
Whatever text you wanted to be returned to be embedded in the web page
would be found in @ANS. AREV had an internal Basic function called
Eval(MyCode) that would evaluate a string containing basic code, compile
it, and execute it; I am suggesting a similar method.

Peter

Peter


>
> g.
>

[Peter Walter]

On 6/25/2013 1:11 PM, geneb wrote:
>
> I'd rather see the apache module doing it the way I suggested in order
> to keep from trying to pass potentially huge command lines to the system.
>
> Were you thinking something along the lines of :
>
> sdme_exec /path/to/temp-file
>
> With output going to stdout?

Not really - most of what you would be doing with the web page would be
using pretty short snippets of code, such as

<?sdme
@ANS = @RECORD<3>
?>
to populate some html element or the other. Long programs, and long
command lines, would be encapsulated in PROCS or programs just like any
other, as in:
<?sdme
CALL MYPROG
?>
or
<p class="report">
<?sdme
EXECUTE "LIST MYFILE WITH {long list of fields and selection criteria}"
?>
</p>
to display a report onscreen.

You can pass parameters to the program using special @variables that
access the Apache webserver variables.

Peter

[geneb]

On Tue, 25 Jun 2013, Peter Walter wrote:

> Not really - most of what you would be doing with the web page would be using
> pretty short snippets of code, such as
>
> <?sdme
> @ANS = @RECORD<3>
> ?>
> to populate some html element or the other. Long programs, and long command
> lines, would be encapsulated in PROCS or programs just like any other, as in:

The snippet above makes NO sense. :) Where did @RECORD get loaded with
data? Remember this is stateless, so if you loaded @RECORD outside the
<?sdme ?> it's in now, the @RECORD above would be empty...

> <?sdme
> CALL MYPROG
> ?>
> or
> <p class="report">
> <?sdme
> EXECUTE "LIST MYFILE WITH {long list of fields and selection criteria}"
> ?>
> </p>
> to display a report onscreen.
>

The <p> element is for paragraph definition.

> You can pass parameters to the program using special @variables that access
> the Apache webserver variables.
>

I'm just not seeing how this is going to go together, so I'm just going to
sit back and watch for a while. :)

[Peter Walter]

On 6/25/2013 1:49 PM, geneb wrote:

On Tue, 25 Jun 2013, Peter Walter wrote:

Not really - most of what you would be doing with the web page would be using pretty short snippets of code, such as

<?sdme
@ANS = @RECORD<3>
?>
to populate some html element or the other. Long programs, and long command lines, would be encapsulated in PROCS or programs just like any other, as in:

The snippet above makes NO sense. :)  Where did @RECORD get loaded with data?  Remember this is stateless, so if you loaded @RECORD outside the <?sdme ?> it's in now, the @RECORD above would be empty...

No - there would be a "session" active, just as PHP code has a sessionid. After the Scarlet code is executed, the session data is saved by the webserver and reloaded whenever necessary. That is how dynamic code works in conjunction with the web server.

<?sdme
CALL MYPROG
?>
or
<p class="report">
<?sdme
EXECUTE "LIST MYFILE WITH {long list of fields and selection criteria}"
?>
</p>
to display a report onscreen.

The <p> element is for paragraph definition.

You can pass parameters to the program using special @variables that access the Apache webserver variables.

I'm just not seeing how this is going to go together, so I'm just going to sit back and watch for a while. :)

Well, a apache module would need to be written, and, while I know what needs to be done, I haven't written C / C++ for over thirty years, and the language & I never did get along. So, to do this, I will need the help of a C/C++ programmer. Are there any volunteers among y'all?

Peter

[Ashley Chapman]

Yeah, this looks desirable but complex!  If you can nail down EXACTLY what is needed, I might be able to do some of the C coding - although I'm a bit short on time at the moment.
 

Peter

--
Ashley Chapman

[Peter Walter]

Thanks, Ashley. I will do everything I can to minimize your effort. In addition to an Apache module, I will research how to create an IIS module, too.

All,
I have bombarded y'all with a number of suggestions on moving ScarletDME forward; before I prepare a summary of the initial changes I am proposing, and a roadmap on how to implement them, I would like to get your take on just a couple more of my questions;

(a) How do y'all feel about shortening the name of the product (not the project) to simply "Scarlet" instead of ScarletDME?
(b) Is there a current version or release number? If so, what is it?
(c) Does anyone have an objection to revising the compiler to accept mixed-case statements? The upper-case only coding style turns younger programmers off.

Peter

[Ashley Chapman]

On 27 June 2013 10:42, Peter Walter <pete...@gmail.com> wrote:

On 6/26/2013 5:59 PM, Ashley Chapman wrote:

On 25 June 2013 19:04, Peter Walter <pete...@gmail.com> wrote:

Well, a apache module would need to be written, and, while I know what needs to be done, I haven't written C / C++ for over thirty years, and the language & I never did get along. So, to do this, I will need the help of a C/C++ programmer. Are there any volunteers among y'all?

Yeah, this looks desirable but complex!  If you can nail down EXACTLY what is needed, I might be able to do some of the C coding - although I'm a bit short on time at the moment.

Thanks, Ashley. I will do everything I can to minimize your effort. In addition to an Apache module, I will research how to create an IIS module, too.

All,
I have bombarded y'all with a number of suggestions on moving ScarletDME forward; before I prepare a summary of the initial changes I am proposing, and a roadmap on how to implement them, I would like to get your take on just a couple more of my questions;

Thanks for your input, which has been great so far.  Like Dicon says "you're amongst friends"

(a) How do y'all feel about shortening the name of the product (not the project) to simply "Scarlet" instead of ScarletDME?

I really don't know how the name came about, but I'm happy if there is no conflict with an existing product.  Some time ago I proposed that we rename the executable from qm to sd as part of the re-branding, but we never got around to it.
 

(b) Is there a current version or release number? If so, what is it?

Don't know!
 

(c) Does anyone have an objection to revising the compiler to accept mixed-case statements? The upper-case only coding style turns younger programmers off.

It takes any case at the moment!  Variable names are case insensitive, so "ash", "Ash" and "ASH" all refer to the same variable.  In fact, the code formatter lowercases things for you automatically (if you use the CASE option). :)

Ashley

[Marcus Rhodes]

Code formatter?  Do tell!

[Ashley Chapman]

On 27 June 2013 11:00, Marcus Rhodes <gaius0...@gmail.com> wrote:

Code formatter?  Do tell!

It's in the manual - under FORMAT :)

Ashle

[geneb]

On Thu, 27 Jun 2013, Peter Walter wrote:

> (a) How do y'all feel about shortening the name of the product (not the
> project) to simply "Scarlet" instead of ScarletDME?

Most of us just call it Scarlet, but I'd like to retain the DME part - it
IS a "Data Management Environment" - the whole hog as it were. Helps
differentiate between what a full MV system is and something like MySQL or
MariaDB.

> (b) Is there a current version or release number? If so, what is it?

I think at some point we settled on an Ubuntu style release number where
it was year-month. Others will have a better memory that I do I suspect.
:)

> (c) Does anyone have an objection to revising the compiler to accept
> mixed-case statements? The upper-case only coding style turns younger
> programmers off.

AFAIK, there's nothing inherent in the compiler that forces the use of
upper case - it's "case agnostic" as it were. :) If there IS something in
there that forces upper case only, it's got to be an optional thing - I
distinctly recall writing code that's all lower case in Scarlet.

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_!

[geneb]

On Thu, 27 Jun 2013, Ashley Chapman wrote:

> On 27 June 2013 11:00, Marcus Rhodes <gaius0...@gmail.com> wrote:
>

>> **

>> Code formatter? Do tell!
>>
>
> It's in the manual - under FORMAT :)
>

This is a pretty huge thing folks - one thing we very much need to do is
come up with our own documentation set.

There's two ways I can see to do this - take the OpenQM 2.6-6 manual set
and paraphrase the entire thing, or approach Ladybridge to see if they'd
be willing to release the 2.6-6 documentation set as open source.

The preference would be to get an open source licese to the old docs, but
if *I* ask, the answer would be along the lines of, "Hell no and don't
darken my doorway again!" :)

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.

[Peter Walter]

On 6/27/2013 10:02 AM, geneb wrote:
> This is a pretty huge thing folks - one thing we very much need to do
> is come up with our own documentation set.
>
> There's two ways I can see to do this - take the OpenQM 2.6-6 manual
> set and paraphrase the entire thing, or approach Ladybridge to see if
> they'd be willing to release the 2.6-6 documentation set as open source.
>
> The preference would be to get an open source licese to the old docs,
> but if *I* ask, the answer would be along the lines of, "Hell no and
> don't darken my doorway again!" :)

Unless someone prefers a different route, I will assign one of my
technical writers to create a GPL-licensed manual set for Scarlet. I
will also put that task on the roadmap.

Peter

[geneb]

S'cuse me whilst I fall out of my chair. :)

Can I get you to do a GPL version of Encyclopedia Pick while you're at
it? *huge grin*

[Wjhonson]

While the intent is laudable, I feel that "Scarlet" generates too many false positives, so many it completely drowns out the information on this product.  Hopefully we want to make it easy for people to find, not hard.

-----Original Message-----
From: Peter Walter <pete...@gmail.com>
To: scarletdme <scarl...@googlegroups.com>

Cc: Ashley Chapman <ashley....@billabong-services.co.uk>
Sent: Thu, Jun 27, 2013 2:42 am
Subject: Re: Hello all

[Peter Walter]

On 6/27/2013 4:31 PM, geneb wrote:
> On Thu, 27 Jun 2013, Peter Walter wrote:
>
>>
>> Unless someone prefers a different route, I will assign one of my
>> technical writers to create a GPL-licensed manual set for Scarlet. I
>> will also put that task on the roadmap.
>>
> S'cuse me whilst I fall out of my chair. :)
>
> Can I get you to do a GPL version of Encyclopedia Pick while you're at
> it? *huge grin*

Sure! I'll do one right after I clear my current projects :-)

The USA Supreme Court, in a decision last year, held that API's can't be
copyrighted (Oracle vs Google), and that describing the API's does not
infringe. As long as we describe what the language elements do,
LadyBridge can't complain even if the language is very similar.

Peter

[Peter Walter]

On 6/27/2013 4:37 PM, Wjhonson wrote:

While the intent is laudable, I feel that "Scarlet" generates too many false positives, so many it completely drowns out the information on this product.  Hopefully we want to make it easy for people to find, not hard.

I did a Google search on "scarlet", and it does not seem to be taken as a recognized mark in the IT domain. If we do the SEO right, it wiould be on the first page of results and easy to find. "ScarletDME" is harder because it isn't obvious what the "DME" is; therefore it merely obfuscates the name. I will defer on this, but I think "Scarlet, the Data Management Environment" is just as easy to find in context as is "Puff, the magic dragon" without anybody confusing Puff with smoking.

Peter

[geneb]

Actually, that wasn't the Supreme Court - I've been following that little
nightmare that Oracle stirred up since its inception.
http://www.groklaw.net is an _excellent_ resource. Oracle has appealed
the lower court decision. Judge Alsop smacked them down pretty
effectively, but I don't know what chance (if any) their appeal has.

I'd REALLY like to avoid stirring up Ladybridge if at all possible - after
all, if it wasn't for their largesse(sp?) we wouldn't have Scarlet to hack
on in the first place. :)

[Peter Walter]

On 6/27/2013 4:54 PM, geneb wrote:
> Actually, that wasn't the Supreme Court - I've been following that
> little nightmare that Oracle stirred up since its inception.
> http://www.groklaw.net is an _excellent_ resource. Oracle has appealed
> the lower court decision. Judge Alsop smacked them down pretty
> effectively, but I don't know what chance (if any) their appeal has.

Sorry. You are completely right.

>
> I'd REALLY like to avoid stirring up Ladybridge if at all possible -
> after all, if it wasn't for their largesse(sp?) we wouldn't have
> Scarlet to hack on in the first place. :)

... and, because of that, I will go the extra mile to ensure that our
docs won't infringe. It will be easier over time as Scarlet diverges
from OpenQM.

Peter

[Wjhonson]

Not sure what you mean, when I do a google search for Scarlet I get 74 million pages.
Surely you don't think that our little project will jump to the first position ?

Not sure what SEO tricks you know, but I'm skeptical

-----Original Message-----
From: Peter Walter <pete...@gmail.com>
To: scarletdme <scarl...@googlegroups.com>

[geneb]

On Thu, 27 Jun 2013, Peter Walter wrote:

> On 6/27/2013 4:54 PM, geneb wrote:
>> Actually, that wasn't the Supreme Court - I've been following that little
>> nightmare that Oracle stirred up since its inception.
>> http://www.groklaw.net is an _excellent_ resource. Oracle has appealed the
>> lower court decision. Judge Alsop smacked them down pretty effectively,
>> but I don't know what chance (if any) their appeal has.
>
> Sorry. You are completely right.

I'll have to frame that. It happens so rarely these days. :) (that I'm
right, not that someone's admitting it.)

>>
>> I'd REALLY like to avoid stirring up Ladybridge if at all possible - after
>> all, if it wasn't for their largesse(sp?) we wouldn't have Scarlet to hack
>> on in the first place. :)
>
> ... and, because of that, I will go the extra mile to ensure that our docs
> won't infringe. It will be easier over time as Scarlet diverges from OpenQM.
>

Thanks, it's hugely appriciated.

[Anthony Youngman]

On 24/06/2013 15:59, geneb wrote:
>> I haven't yet downloaded the source code, but I assume that
>> ScarletDME programs compile to bytecode; and that ScarletDME is
>> written in C. Is it just that the ScarletDME source needs to be
>> modified and recompiled for 64-bit, or is it more complicated than that?
> It's been a while since I looked at it, but the 32 bit compiled byte
> code does not work with a 64 bit running system. It may be as simple
> as writing a conversion utility that will generate a set of 64 bit
> object code files based on the 32 bit object files.
IMHO not a good move.

Not knowing the code at all, but I suspect the object code interpreter
has declared a load of stuff as "int" or similar. Far better to change
those declarations to int32 so that 32-bit object-code runs correctly.

Cheers,
Wol

[Anthony Youngman]

On 24/06/2013 19:58, geneb wrote:
> On Mon, 24 Jun 2013, Ashley Chapman wrote:
>
>>
>> I would be VERY interested in what conclusions you come to here!
>> Ladybridge have their own interpretation of their licence, which is that
>> all aplications that use the GPL Openqm (or ScarletDME), also inherit
>> the
>> GPL, so can only be released with source. I'm not convinced myself, as
>> they use the GPL2 licence, and didn't add any conditions to it in the
>> source code release.
>>
> AFAIK, no changes CAN be made to the GPL. It's an all or nothing
> thing. You can be granted more rights than the GPL conveys, but not
> fewer.

Ummm ... yes ...

You can't change the GPL. It's a copyrighted document. BUT.

When you release a program and apply a licence to it, you can put
whatever you like in the licence document. So there is nothing to stop
me saying in my COPYRIGHT file "this program is licenced according to
the GPL with the following changes, 1,2,3".

It's the LICENCE file that governs in court, not the GPL. The GPL only
applies if the licence file says it applies. This is what Ladybridge
have (tried to) do - OpenQM is "GPL with additions". A bunch of people
who know what they're talking about (debian.legal) have voiced a fair
bit of unhappiness with the licence.

Cheers,
Wol

[geneb]

On Fri, 12 Jul 2013, Anthony Youngman wrote:

> It's the LICENCE file that governs in court, not the GPL. The GPL only
> applies if the licence file says it applies. This is what Ladybridge
> have (tried to) do - OpenQM is "GPL with additions". A bunch of people
> who know what they're talking about (debian.legal) have voiced a fair
> bit of unhappiness with the licence.
>

Wol, what "additions"? I take it I've missed something. ( not surprising!
:) )

[Anthony Youngman]

On 12/07/13 14:58, geneb wrote:
> On Fri, 12 Jul 2013, Anthony Youngman wrote:
>
>> It's the LICENCE file that governs in court, not the GPL. The GPL only
>> applies if the licence file says it applies. This is what Ladybridge
>> have (tried to) do - OpenQM is "GPL with additions". A bunch of people
>> who know what they're talking about (debian.legal) have voiced a fair
>> bit of unhappiness with the licence.
>>
> Wol, what "additions"? I take it I've missed something. ( not
> surprising! :) )
>

It's precisely this bit about having to distribute the source for
applications with the binary, when the app merely sits on top of the
database.

Firstly, I (and this was debian.legal's viewpoint too) was very unhappy
with the claim that my application binary was, legally, a derivative of
the database itself. Secondly, the GPL explicitly permits linking to
"stuff the application can assume is supplied by the underlying system"
(this does have the legal implication that you could supply Scarlet OR
your app, but not both ... :-)

And having looked at Ladybridge's page on OpenQM, various debian.legal
people commented that it looked very much like Ladybridge didn't
actually understand the GPL. The general reaction was "don't touch it
with a bargepole". Especially because of the claim "this is GPL" and
then the claims that you can't do a load of things that people expect as
a matter of course with vanilla GPL. The consensus was that the risk of
being sued for doing something the GPL allows was too high.

Of course, all of this is moot if you take out an OpenQM licence, which
is what Martin and Ladybridge want, but this is also the scenario which
the GPL is intended to prevent.

(Just to point out, debian.legal is a hangout for armchair lawyers with
no actual authority, but many of the people there *do* know what they're
talking about.)

(Do you remember me getting under Martin's skin when OpenQM was first
released? And he threatened to pull it if people abused it? That was why
I shut up, I didn't want to spoil it for everyone. But I expected it to
end in tears, and it looks like it did ...)

Cheers,
Wol

[Wjhonson]

I think all of that is also going to be dependent on whether LadyBridge *actually* tries to sue any one for writing apps and then selling them, using the free underlying environment.

-----Original Message-----
From: Anthony Youngman <wolw...@gmail.com>
To: scarletdme <scarl...@googlegroups.com>
Sent: Fri, Jul 12, 2013 11:38 am
Subject: Re: Hello all

On 12/07/13 14:58, geneb wrote:
> On Fri, 12 Jul 2013, Anthony Youngman wrote:
> 
>> It's the LICENCE file that governs in court, not the GPL. The GPL only
>> applies if the licence file says it applies. This is what Ladybridge
>> have (tried to) do - OpenQM is "GPL with additions". A bunch of people
>> who know what they're talking about (debian.legal) have voiced a fair
>> bit of unhappiness with the licence.
>>
> Wol, what "additions"?  I take it I've missed something. ( not
> surprising! :) )
> 
It's precisely this bit about having to distribute the source for
applications with the binary, when the app merely sits on top of the
database.

Firstly, I (and this was debian.legal's viewpoint too) was very unhappy
with the claim that my application binary was, legally, a derivative of
the database itself. Secondly, the GPL explicitly permits linking to
"stuff the application can assume is supplied by the underlying system"
(this does have the legal implication that you could supply Scarlet OR
your app, but not both ... :-)

And having looked at Ladybridge's page on OpenQM, various debian.legal
people commented that it looked very much like Ladybridge didn't
actually understand the GPL. The general reaction was "don't touch it
with a bargepole". Especially because of the claim "this is GPL" and
then the claims that you can't do a load of things that people expect as
a matter of course with vanilla GPL. The consensus was that the risk of
being sued for doing something the GPL allows was too high.

Of course, all of this is moot if you take out an OpenQM licence, which
is what Martin and Ladybridge want, but this is also the scenario which
the GPL is intended to prevent.

(Just to point out, debian.legal is a hangout for armchair lawyers with
no actual authority, but many of the people there *do* know what they're
talking about.)

(Do you remember me getting under Martin's skin when OpenQM was first
released? And he threatened to pull it if people abused it? That was why
I shut up, I didn't want to spoil it for everyone. But I expected it to
end in tears, and it looks like it did ...)

Cheers,
Wol

-- 
You received this message because you are subscribed to the Google Groups 
"ScarletDME" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to scarletdme+...@googlegroups.com.
To post to this group, send email to scarl...@googlegroups.com.
Visit this group at http://groups.google.com/group/scarletdme.
For more options, visit https://groups.google.com/groups/opt_out.