Pick PHP

#21

On Mar 7, 2:08*pm, Tony Gravagno
<address.is.in.po... (AT) removethis (DOT) com.invalid> wrote:

Quote:

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

This con happen at one of two levels - MV Vendors, MV 3rd party tools.

At the MV Vendor level it requires that these guys get together and
develop a standard for database communication such as ODBC. OMVC
anyone? I don't see this happening any time soon as MV vendors have
shown that they are very happy to perpetuate vendor lock-in.

The other level from which to attack this 3rd party tools. In the SQL
world, all of the popular databases have various levels of ODBC
compatibility, but ODBC is a lowest common denominator translation
layer that may not have include all database-specific features/
functions. If you want better performance, you need to use native
database drivers or API. Of course, going down the native driver
route means incompatibility across database platforms.

What some enterprising tool providers have done is to create a single
set of data access components (DAC) that incorporate the native
drivers/api of the popular databases they target (Oracle, MySQL, SQL
Server, PostgreSQL, etc). So, with a single set of DACs one can
communicate with all of their favourite SQL databases without having
to ever change their code.

Some of these DACs wrap the vendor's drivers, so these drivers must be
present for them to work, but some of the really good ones actually
use database APIs directly.

--
Kevin Powick

#22

RJ wrote:

Quote:

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

Risks -

The need you apparently see is to transform the products of the
"superior prototyping system" into lower risk applications. Or to
replace them with lower risk applications.

Do you really think this is a technologically solvable problem? If so,
how? If not, then why not use the original "superior prototype" and
simply apply it in a different culture, or whatever will reduce its risks?

We've seen lots of "superior prototypes" dropped or transformed. Is
there a clear idea of what was specifically extracted from the prototype
technology into the descendent (by someone's judgment lower-risk)
applications? In fact, has the level of 'risk' inherent in the superior
prototypes been explicitly addressed when contemplating or committing to
replacement?

If the risks inherent in the superior prototypes are not technically
addressable, then let the politicians have at them, and let their
genetic alterations see how they fare in their use. If the risks
inherent in the superior prototypes are technically addressable, then we
will profit from appropriately evolving them. That business model would
have some heft.

Risks are generally measured at ground level - I will buy to resolve my
worries. What are the top three worries of the owners (or IT managers)
of "superior prototypes"? I'd like to know. We need to know. How do
they describe and quantify those risks?

Or are the people who will guarantee the survival of the mv technology
those tool and app builders who need a common interface, regardless of
the species of mv? Are their critical risks inherent in the mv app
servers themselves, or the apparant diversity in the mv server alternatives?

Crocodiles have survived - measured against risks of annihilation -
without their maker deciding to redesign them to fit current impressions
of risk of fitness.

By the way, parts count is a universal measure of engineering cost and
risk. Crocodiles don't even use warm-bloodedness parts.

-- Bill Cooke

#23

I was typing a reply and it disappeared. Maybe I angered the Gods. The
essence of the disappeared response was that the Force acts in mysterious
ways. Who in his right mind would select Windows for business or Oracle for
that matter. And why does the technically inferior product often seem to
capture the market - eight track tape for instance? So how can any human
know why the MV environment is following T. Rex while SQL, Oracle, Windows
persist with their Crocodilian smiles.
BobJ
"Bill Cooke" <bcooke (AT) cookedata (DOT) com> wrote

Quote:

RJ wrote:

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

Risks -

The need you apparently see is to transform the products of the "superior
prototyping system" into lower risk applications. Or to replace them with
lower risk applications.

Do you really think this is a technologically solvable problem? If so,
how? If not, then why not use the original "superior prototype" and
simply apply it in a different culture, or whatever will reduce its risks?

We've seen lots of "superior prototypes" dropped or transformed. Is there
a clear idea of what was specifically extracted from the prototype
technology into the descendent (by someone's judgment lower-risk)
applications? In fact, has the level of 'risk' inherent in the superior
prototypes been explicitly addressed when contemplating or committing to
replacement?

If the risks inherent in the superior prototypes are not technically
addressable, then let the politicians have at them, and let their genetic
alterations see how they fare in their use. If the risks inherent in the
superior prototypes are technically addressable, then we will profit from
appropriately evolving them. That business model would have some heft.

Risks are generally measured at ground level - I will buy to resolve my
worries. What are the top three worries of the owners (or IT managers) of
"superior prototypes"? I'd like to know. We need to know. How do they
describe and quantify those risks?

Or are the people who will guarantee the survival of the mv technology
those tool and app builders who need a common interface, regardless of the
species of mv? Are their critical risks inherent in the mv app servers
themselves, or the apparant diversity in the mv server alternatives?

Crocodiles have survived - measured against risks of annihilation -
without their maker deciding to redesign them to fit current impressions
of risk of fitness.

By the way, parts count is a universal measure of engineering cost and
risk. Crocodiles don't even use warm-bloodedness parts.

-- Bill Cooke

#24

I agree with you Tony that were all the Vendors to get together and
agree on a standard that would be better for the environment
altogether. I also agree that it's not likely to occur.

The advantage I see in writing a database using only PHP is that when
done, you have a system which is Pick, but actually lives in a web
server environment natively. Not one that is being beaten and prodded
and forced to somehow adapt to this new environment, but one that grew
up there.

Access to it, is neat and clean, not bizarre looking. And all PHP
programmers suddenly say, hey look at this nifty database that gives
us high-availability multi user random access without so much need for
JOINs. Heck that's a great leap over what we had before. They don't
need to know that it came from the Pick Swamp. Anything is better
than the twisted file access that we have to do today.

#25

P.S. The reason why I'm not keen on CLR is that it's tied to MS. I
would rather write in a language that can run on any type of web
server.

#26

wjhonson wrote:

Quote:

P.S. The reason why I'm not keen on CLR is that it's tied to MS. I
would rather write in a language that can run on any type of web
server.

This is exactly why I'm not talking about going down the rathole with
a specific set of tools - as soon as you do that the other x% of the
market says "fooey, you aren't using MY tools".

BTW, the CLR is Not tied to MS - the CLR is an open spec which has
been implemented in Mono, and Mono runs on *nix, Mac, Windows, and
other platforms.

You guys aren't quite getting my intent yet, and while I should just
tell you to wait for the paper, here's the gist...

All MV platforms support Login, Open File, Read, Write, Call, etc.
All libraries created to date support at least those functions,
sometimes with syntax like File.Open(name), sometimes with
Account.FileOpen(name). What I propose is a single API definition,
where object-oriented languages can do this:

account = MvAccount.Login(accountName)
file = account.FileOpen(fileName)
item = file.Read(itemID)
atb2 = item[2]

Every language has slightly different syntax. Syntax is irrelevant.
The important part is that there will be an MvAccount class (or
similar) which has a Login method that accepts an account name as a
parameter. I can implement this in Java and C#, you can do it in PHP,
someone else can do it in Ruby or Fortran. But all implementations
must conform to the API.

Any language binding should be able to connect to any MV platform
simply by changing the ID for the platform. Above the account, file,
item tier demonstrated above, the developer must identify the target
platform, its location, and the mechanism used to communicate with
that server. For example:

environment = MvEnvironment("QM","myServer1", "QMClient")

In the language binding, the class library which implements the API,
developers can create comms-specific bindings to each platform. QM
supports QMClient, Telnet, and mv.NET. U2 supports UO, UO.NET, and
mv.NET. D3 supports the D3 Class Library, ODBC, and will have the new
..NET and Java libraries.

The application developer will not be concerned with the mechanics of
How their code connects into the target system. They only need to
make sure that they can. So for example, there will be a QMClient
interface for Java Test with the Java MVAPI binding, and if this works
in any given installation then an app written with the Java MVAPI
should be able to connect into a QM system as well.

Note: MV DBMS vendors do not need to help with this at all. They have
already created the comms interfaces, and that's all we need. This
entire project can be undertaken now, by anyone who knows a language
other than BASIC. The first step is to get consensus on the basic API
to which the language bindings will conform. I've already defined the
spec ... I just need time to proof-read my papers a few times to
introduce the material properly (and I need to figure out a way to get
paid for trying to help DBMS vendors and VARs to sell more of their
software ... sheesh).

T

#27

On 03/08/2010 12:42 AM, Tony Gravagno wrote:

Quote:

wjhonson wrote:

P.S. The reason why I'm not keen on CLR is that it's tied to MS. I
would rather write in a language that can run on any type of web
server.

This is exactly why I'm not talking about going down the rathole with
a specific set of tools - as soon as you do that the other x% of the
market says "fooey, you aren't using MY tools".

[snip]

Good stuff there, Tony. What you say makes a great deal of sense.
--
Cheers, SDM -- a 21st Century Schizoid Man
Systems Theory project website: http://systemstheory.net
find us on MySpace, GarageBand, Reverb Nation, Last FM, CDBaby
free MP3s of Systems Theory, Mike Dickson & Greg Amov music at
http://mikedickson.org.uk

#28

On Mar 8, 12:42*am, Tony Gravagno
<address.is.in.po... (AT) removethis (DOT) com.invalid> wrote:

Quote:

wjhonson wrote:
P.S. *The reason why I'm not keen on CLR is that it's tied to MS. *I
would rather write in a language that can run on any type of web
server.

This is exactly why I'm not talking about going down the rathole with
a specific set of tools - as soon as you do that the other x% of the
market says "fooey, you aren't using MY tools".

BTW, the CLR is Not tied to MS - the CLR is an open spec which has
been implemented in Mono, and Mono runs on *nix, Mac, Windows, and
other platforms.

You guys aren't quite getting my intent yet, and while I should just
tell you to wait for the paper, here's the gist...

Sounds good Tony. But after all that work, if people start saying, oh
gee why you doing all that?
This here WJPD (Will Johnson's PHP Database) has all the advantages of
your Pick database, and runs natively on the web server. It can even
reach into your legacy Pick system and pull data out of there as well.

We're gonna put the old MvBase, D3, Universe, AR system under
maintenance only while our new fangled web guys work in PHP beefing up
the WJPD system....

We'll always have legacy systems, but what are the bleeding edge
companies converting... to ?
I see a lot more jobs for web type applications than anything else.

Will

#29

On Mar 8, 3:47*pm, wjhonson <wjhon... (AT) aol (DOT) com> wrote:

Quote:

We're gonna put the old MvBase, D3, Universe, AR system under
maintenance only while our new fangled web guys work in PHP beefing up
the WJPD system....

Please send me the contact information for your "pharmacist"... You
know, the one that wears a jean jacket instead of a lab coat.

--
Kevin Powick

#30

Kevin Powick wrote:

Quote:

On Mar 8, 3:47*pm, wjhonson wrote:

We're gonna put the old MvBase, D3, Universe, AR system under
maintenance only while our new fangled web guys work in PHP beefing up
the WJPD system....

Please send me the contact information for your "pharmacist"... You
know, the one that wears a jean jacket instead of a lab coat.

Yeah, I'm sorry Will but I think your faith in people and technology
is misplaced. You're never going to find an army of people to write
you a new MV database ... for free. You're never going to find
someone who has any sense writing a real DBMS in PHP.

Will, the one strength you cite is that the DBMS will run on the web
server. Well, on one hand, all databases, relational and otherwise,
will run on a web server. On the other hand, SOP is to run databases
on a separate server anyway.

You don't need to write a DBMS in PHP to make it run with a web
server. In fact it seems the premise of your whole discussion is
centered around the elegance of using the same language for apps and
DBMS. You need to open up a bit to the concept that software these
days exists in many tiers, and it doesn't matter what languages are
used at each tier anymore. You use the right tools/languages to suit
the jobs - and while PHP script is well suited to web applications,
it's not well suited for writing engines like databases or other
servers.

Will wrote:

Quote:

But after all that work, if people start saying, oh
gee why you doing all that?

Look a the "cURL" project which has a number of language bindings and
it's _extremely_ popular. Also check out most any cloud-based SaaS
platform these days (Google, Twitter, Facebook, and hundreds of
others) and you'll find a well-defined API with a collection of
language libraries that implement it. Why do that? Well dude, that's
the way it's done these days because it allows everyone to contribute
to the platform, _and_ it allows everyone to incorporate the core
platform (via mashups) into whatever application they like with their
language of choice.

(IMO this thread is starting to suffer from interest rot, my own
anyway)

T