Pick PHP

#11

Top posting because most won't want to read it all again - I think.

I agree with almost everything tony said in this surprisingly succinct post
but I do have one question of two parts.

Part one - How do we come even close to being security and audit conscious
when a file may or may not have a dictionary and even if it has a dictionary
there is no assurance that the dictionary is telling the truth, and even if
the dictionary is accurate somebody has probably used the editor to scramble
the data?

Part two - How do we get rid of procs, correlatives, and limit the system
to one language, namely Basic?

If those two reservations were removed then we would have a truly powerful
platform. That mousetrap would be so much better that the world would
trample each other building the path to our doorstep.

But what will probably happen is that somebody will develop a method of
using the better parts of MV file structure as a class in a library and the
world continues to plod along the same old path with half the world writing
VB and the other half asking them when they are going to become real
programmers.

An old saying among poker players is "if you want to know how good you are,
count your money." I think Bill Gates may have a little more than even
those of us who have lived reasonably well from our efforts with MV.

Just one old man's thoughts.

BobJ

"Tony Gravagno" <address.is.in.posts (AT) removethis (DOT) com.invalid> wrote in
message news:qmh5p55l888o3d0vbosl9qq7shfl5vjfja (AT) 4ax (DOT) com...

Quote:

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

#12

Bob- the platform is what it is. All MV vendors have implemented some
form of security, we're not going to get rid of procs or correlatives,
and there's no good reason to limit a platform to one language. Let's
build upon it rather than picking nits and finding yet new reasons why
it should never be used outside of the small base that exists. I
think we'd be taking a step backward to scale Down the platform for a
new audience. (Arguably) we offer more than the other guys - that's a
strength, not a weakness. If there is a business case for the DBMS
vendors to make changes for a different audience then they will - or
they will simply stay where they are, in a profitability stalemate,
wondering how else they can make best use of their assets to generate
income. (How about actually trying to sell what you have? Duh...)

T

#13

"Tony Gravagno" <address.is.in.posts (AT) removethis (DOT) com.invalid> wrote in
message news:d5q5p5tffhvi28lq5fls7hdvip2lcdjdi4 (AT) 4ax (DOT) com...

Quote:

Bob- the platform is what it is. All MV vendors have implemented some
form of security, we're not going to get rid of procs or correlatives,
and there's no good reason to limit a platform to one language. Let's
build upon it rather than picking nits and finding yet new reasons why
it should never be used outside of the small base that exists. I
think we'd be taking a step backward to scale Down the platform for a
new audience. (Arguably) we offer more than the other guys - that's a
strength, not a weakness. If there is a business case for the DBMS
vendors to make changes for a different audience then they will - or
they will simply stay where they are, in a profitability stalemate,
wondering how else they can make best use of their assets to generate
income. (How about actually trying to sell what you have? Duh...)

T

In the old days we could sell a sloppy prototype for a good price because
the other guys just could not show results in the same time frame. The
users were naïve and so were we. We were good so the bugs were more or less
contained. But if the vast army of VB programmers worked in the
undisciplined Pick environment we would see world wide chaos. But you are
right for the wrong reason. We can ONLY sell what we have, and what we have
is a superior prototyping system. The small business man can trade the risk
of our product versus the cost of the other guys product - which is risky,
too - and make his decision. The IT manager in a major company has to
subscribe to the modern version of the old saying "nobody ever got fired for
choosing IBM".

So the bottom line is you made a good decision when you scrapped the
project. Selling MV in today's world is swimming upstream against a very
strong current. Leave it for the Salmon. After all, Bad Odor has declared
that MV is blasphemy.

BobJ

#14

Your last delusion? Or you last use of rose-colored glasses?

My question is not, can we make routines to access some existing Pick
database.

My is question is regarding a much more primitive construction.

Can we, in PHP, create all the routines, to create and manage a Pick
database, built entirely within, by and for PHP.

That is what my first part meant.

Will

#15

This is RTF - hope it doesn't give problems.

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

Quote:

Your last delusion? Or you last use of rose-colored glasses?

My question is not, can we make routines to access some existing Pick
database.

My is question is regarding a much more primitive construction.

Can we, in PHP, create all the routines, to create and manage a Pick
database, built entirely within, by and for PHP.

Ah, read and understand - not read and think he said what you want to see. Pick Data Base. If by that you mean just the files including the ability to access the related files, attributes, values, maybe subvalues through dictionary entries then the answer is obviously yes. I think you are saying that you have no intention of implementing Reverse Polish Notation. And maybe you mean Paragraphs and Phrases rather than procs, or maybe you mean nothing but the files.. And finally, you may mean use the editor in the calling language rather than the traditional Pick editor. So if you are writing a Ruby program for instance you would have a class that handles Locate, Insert, Delete. The same class or possibly another in the same name space would handle read and write but the "home" system would handle open and lock and probably Transactions. Since I don't know the first thing about PHP I can only hope that the "class" analogy would work there. I say "the obvious answer is yes" above because I've heard that PHP is a good scripting language and that's virtually the only requirement to do what I think you said you want to do.

Quote:

That is what my first part meant.

I have no idea what the commercial prospects would be but it would definitely be useful. It would be most useful, I think, if the nested data were made a part of something like MySQL. Otherwise it is really just a File Handler - but a useful one.

And a question of my own - why not implement it in one of the languages that compiles to the Microsoft CLR and thus capture some of the millions of VB programmers out there?

BobJ

Quote:

Will

#16

On Mar 6, 6:12*pm, "RJ" <nob... (AT) nowhere (DOT) com> wrote:

Quote:

* Part one - How do we come even close to being security and audit conscious
when a file may or may not have a dictionary and even if it has a dictionary
there is no assurance that the dictionary is telling the truth, and even if
the dictionary is accurate somebody has probably used the editor to scramble
the data?

How is this any different than dead/unused fields in a RDBMS, fields
with no checks, triggers, foreign key constraints, etc? Just because
most SQL type databases force you define the fields before use does
not make the validity of the table structure, or the data within it,
any better than that of a MV file.

Quote:

* *Part two - How do we get rid of procs, correlatives, and limit thesystem
to one language, namely Basic?

I agree that PROC should have gone the way of the Dodo by now, but
what are you after here from a "security" perspective?

In the SQL/RDBMS world, there are many ways to access the data beyond
standard SQL. Native APIs, ODBC, OLEDB, etc. allow you access and
update data via a plethora of languages and 3rd party tools. Also,
features of such databases, such as triggers, stored procedures,
functions, etc allow you to manipulate the data and make just as many
mistakes as a MV database.

--
Kevin Powick

#17

All true. The heart of my complaints or concerns is the dictionary entry
that lies. It's just too easy to create that situation in our world. Every
Pick developer but you and I has created such a monster - and I'm not so
sure about you

BobJ

"Kevin Powick" <kpowick (AT) gmail (DOT) com> wrote

Quote:

On Mar 6, 6:12 pm, "RJ" <nob... (AT) nowhere (DOT) com> wrote:

Part one - How do we come even close to being security and audit
conscious
when a file may or may not have a dictionary and even if it has a
dictionary
there is no assurance that the dictionary is telling the truth, and even
if
the dictionary is accurate somebody has probably used the editor to
scramble
the data?

How is this any different than dead/unused fields in a RDBMS, fields
with no checks, triggers, foreign key constraints, etc? Just because
most SQL type databases force you define the fields before use does
not make the validity of the table structure, or the data within it,
any better than that of a MV file.

Part two - How do we get rid of procs, correlatives, and limit the
system
to one language, namely Basic?

I agree that PROC should have gone the way of the Dodo by now, but
what are you after here from a "security" perspective?

In the SQL/RDBMS world, there are many ways to access the data beyond
standard SQL. Native APIs, ODBC, OLEDB, etc. allow you access and
update data via a plethora of languages and 3rd party tools. Also,
features of such databases, such as triggers, stored procedures,
functions, etc allow you to manipulate the data and make just as many
mistakes as a MV database.

--
Kevin Powick

#18

On Mar 7, 12:05*pm, "RJ" <nob... (AT) nowhere (DOT) com> wrote:

Quote:

All true. *The heart of my complaints or concerns is the dictionary entry
that lies. *It's just too easy to create that situation in our world.

I'll give you that a MV dictionary can more easily totally
misrepresent the contents of its associated MV file, but the only
thing you can be assured of when looking at a SQL table is that the
data is of the correct type (int, date, char, etc). However, that
doesn't mean the data is correct. I've seen Char/VarChar fields that
were supposed to represent strictly numerical data, but the developer
chose Char to reduce the number of application side conversions/
castings. This results in a field easily corruptible with non
numerical data.

In the end, the looseness of MV offers a lot of flexibility/power, but
also results in more responsibility falling on developers to ensure
data integrity. Whereas, in the SQL world, much of that
responsibility *can* fall upon the DB Administrator.

--
Kevin Powick

#19

If you guys are talking about creating a new MV platform with PHP (or
managed CLR language) I'd say there's no point to doing so. It's not
worth the effort when there are a number of existing and well
supported platforms to choose from. We've already seen a couple
failed FOSS MV platforms and OpenQM is dangerously close to joining
them (not commercial QM but the open source version for *nix).

Developers don't need an open source DBMS written in their favorite
language. And as soon as you write a DBMS in one language you
alienate everyone else. People don't mind a packaged DBMS as long as
they can access it with their preferred tools. Right now every MV
platform is accessed differently and the language bindings are
inconsistent (or non-existent) for every platform. My (rosey) view is
that if we can tell people they can access any MV platform, in a
consistent manner, using any language they want, over any OS they
want, then we'll be in an excellent position to present the MV Stack
as an alternative platform to LAMP, .NET, RoR, and others. In short,
that means developers can write their front-end in any language, and
then write their business rules in BASIC, just like the rest of us.
This is where our strengths lie and we need to make it easy for others
to plug in and start using it quickly.

T

#20

Follow-on to Kevin's comments: Relational databases have Tables and
Views. The View is a collection of fields for one or more tables.
The View is roughly equivalent to a collection of dict items that are
created for a specific purpose, separate from other collections of
dict items for other purposes. Views can become as obsolete as any
group of dict items like Name20 Bal$.Test Frank Frank2 XX%. The
analogies are very rough here but the point here is that you can make
a mess in any environment. The solution isn't to remove features but
to do better administration. This is why other platforms have
DataBase Administrators (DBAs) whose job is to manage these
definitions and their relations. In the MV world this task is left to
the developers, and as Kevin said, it's their responsibility to clean
up the dicts once in a while. Few MV sites will pay for such things
while for an RDBMS it's assumed that this is a regular activity. It's
the developers who are sloppy, it's not the platform that's deficient.

T