Two part question.
Would it be even possible, to write all the routines needed to
recreate a Pick-style database on a server, using only PHP?

Part two, what kind of market might be interested in such a product?

Will J

"wjhonson" <wjhonson (AT) aol (DOT) com> wrote

One part opinion. A Pick-style database manager might catch fire if it were
complete. Complete? I mean with referential integrity and WITHOUT the
excess baggage that was included originally because there was no programming
language and the intent was to supply a system that the user could use
without a programmer. The old, experienced Pickies would scream with anger
and anguish without proc and correlatives but nobody who would actually
spend any money on the new system would hear them - or care.

Referential integrity? Simple but complicated. There should be no easy way
to address data without going through a complete dictionary. There must
always be a way to get to the nitty gritty but it should not be for general
use.

The Pick style Basic is the easiest language that I have ever used and does
not need much to be "complete" in the sense of using the Windows-like (or
Apple-like if you prefer) user interface and closer ties to Windows itself.
Nix users are already a little closer.

Finally, should it be SQL compliant? Why bother if it is - just use SQL?

Implementation language? Who cares? But if I were choosing then I would
get much closer to the iron - probably C++.

BobJ

On Mar 5, 4:46*am, wjhonson <wjhon... (AT) aol (DOT) com> wrote:
I was thinking of doing one with MS DOS batch files on Windows
platforms to start, then I would be looking for community support to
port this effort to Bash scripting on *nix.

To be slightly more serious. PHP is a general purpose scripting
language, not at all suited to the rigours and requirements of a multi-
user DBMS of any kind.

--
Kevin Powick

Tony already wrote this, but mothballed it, don't you know?

--
frosty


"wjhonson" <wjhonson (AT) aol (DOT) com> wrote

On 5 Mar, 09:46, wjhonson <wjhon... (AT) aol (DOT) com> wrote:
I don’t know how to help with the "creation" of a Pick-like database
entirely in PHP, but if you wanted to "access" a Pick-like database
through PHP, Revelation Software has a product that lets you
communicate from PHP with their multivalue engine. Would that help?

This is getting spooky! Two replies from Martyn/Martin Phillips, both
with much the same story.

It is also possible to access QM from PHP.

As far as the original posting goes, I am not sure why anyone would
want to reimplement the multivalue world directly in PHP. I also
suspect that some of the fundamental mechanisms such as locking may
prove difficult though I am not a PHP expert.


Martin (the other one) Phillips, Ladybridge Systems.

On Mar 5, 11:39*am, "frosty" <fros... (AT) bogus (DOT) tld> wrote:
I had forgotten about that. Below is a link to Tony's site and the
project.


http://PleaseRemoveThisToGetToMySite...mvDataBase.htm

--
Kevin Powick

On Mar 6, 3:39*am, "frosty" <fros... (AT) bogus (DOT) tld> wrote:
He could re-activate .... at least there is demand now (you ARE
willing to pay, aren't you ;-)

After your observation last time, me thinks a troll.

On Mar 5, 2:44*pm, Ross Ferris <ro... (AT) stamina (DOT) com.au> wrote:
Can I be a troll if my experience in Pick predates yours?
I think we've all learned that "trolls" are merely people you don't
want to talk.
It's all very subjective.

Why would I pay, when I'm doing the work?
I'll take a look at what Tony has, maybe I can incorporate it.

As far as the question about the locking table above, locking is just
a table lookup, it's actually fairly easy to implement.
The primary requirement is simply to make your data tables frankly
inaccessible to any device trying to access them without going through
your set routines.

Very few people are crazy enough to try to build external data
walkers, parsing the field and record values and walking the group
pointers without just using the built-in tools to do it. So as long
as I rebuild it just as R83, I would hope that would make that part of
it fairly safe.

Will

I'm laughing at the troll, the responses, and the failure of some
people to get it.

PHP is object-oriented and it's fairly easy to create a PHP class
library which wraps DBMS access. Yes, I started this, convinced
myself that a full implementation was possible, then promptly dropped
it for lack of a business case.

I wrote a white paper over a year ago about creating MV language
"bindings" for PHP, Perl, Java, .NET, Ruby, C++, and others. The idea
was that we would have a standard API supported for all MV platforms
and people would just contribute to fill in the blanks for their
language of choice. The problem we have now is that for every
platform and language there is a different API. The D3 Class Library
is different from QMClient, which is different from UO, which is
different from mv.NET, which is different from PDP.NET, which is
different from the new D3v9 .NET and Java libraries. I think we can
have a single cross-platform API, and change target platforms with a
simple Property setting. I still believe this idea has a lot of
value. Unfortunately I never published this paper but I pledge to do
so within the next few weeks.

Another related paper (also to be published soon) documents a goal to
position QM and/or OpenQM as part of a new stack alternative to RoR,
LAMP, and .NET. There's no reason why people need to feel compelled
to write business logic in PHP or JavaScript, for example, and it's
insane to do so, though this is what the world currently accepts as
the SOP. BASIC was created for beginners, the MV platform is as easy
as MySQL and much more feature-rich, and with proper community/viral
marketing it should be able to get some traction. Why not other
platforms? Cost. Simple as that. Force people to pay too much for
your software and only a few people will use it. Make it afordable
and it may become a worldwide standard. If the other MV providers see
a benefit they'll probably adapt to the model. So far I've discussed
this with a few of the MV providers and none of them seem interested -
or perhaps they just don't get it. Whatever - lead, follow, or get of
the way.

The business model that I see for the above is that people will be
welcome to work on the platform by themselves, or they can contract
with our ragtag collection of long-term experts here to assist with
binding development and maintenance, tutoring/mentoring, etc. Sound
silly? Well that's how the rest of the world seems to work so why
should we be any different. Just look on your local bookstore shelves
for books on all of the above mentioned technologies, and look around
for people selling their development services.

That's my current delusion as seen through the rosey glasses - and
probably my last for this market.

T