"frosty" wrote:
I get frustrated that a good idea like introducing MV to PHP people
gets confused with writing an MV DBMS in PHP. If that can be taken
off the table the discussion would be much more reasonable.

John's note above about Ruby represents an example of what I was
talking about with language bindings to existing MV databases. While
I appreciate the value of an ORM tier, if I'm understand you properly
John, I'm thinking that ORM ~= MVC and since that abstracts the Model
from the View, your ORM interface would be completely abstracted from
the DBMS. In other words, sure, so the ORM with Ruby or PHP or any
other language, then you're working with business objects, not
databases. So behind the ORM, at the DAL tier, it doesn't matter what
the DBMS looks like, how it's accessed, or even what languge is used.

Let's say we entertain the idea of a Ruby or PHP interface to MV. I
invite you to go back to look at my notes about the API for MV,
implemented in any number of languages. Well, once you've implemented
the API, it actually doesn't matter anymore if the back-end is MV or
not. So ... we start with MV, create an API, implement it in a PHP
class library. Now we have something like Item = New MVItem() in PHP,
and Item.DCount() to get the number of attributes. Now we don't even
need the MV DBMS : someone who is really fond of MySQL or delimeted
files or Amazon SimpleDB can use that class library and refit the
back-end with a different platform. So your MVFile.Open("name")
method may create a handle to a MySQL table, or provide access to an
Amazon datastore. People who specialize in each back-end can enhance
the back-end code for their platform of choice - as long as they don't
coerce the MV API with platform-specific dependencies.

The goal of introducing MV to non-MV people is accomplished without
requiring them to use MV. If they want a "real" database behind the
functionality, they can swap out the back-end, try whichever MV
platform they wish, and not have to change any of their PHP code.

Is that a plan which keeps all sides happy?
I'd be happy if a consortium of the MV DBMS providers would fund that
project (it is after all designed to introduce a new mainstream world
of developers to the MV platform where companies are struggling to
maintain profitability). I'd be happy to run it and coordinate all
development - as long as I can feed my family in the process.

Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells Pick/MultiValue products
worldwide, and provides related development services
remove.pleaseNebula-RnD.com/blog
Visit PickWiki.com! Contribute!
http://Twitter.com/TonyGravagno

On Mar 13, 4:11*pm, Tony Gravagno
<address.is.in.po... (AT) removethis (DOT) com.invalid> wrote:

IMO, language bindings, or an API, that gives you MV functionality
such as Read, Extract, Insert, DCount, etc, work against the power
that's built right into the MV database. You really only need one
thing; The ability to call subroutines and have them return the data
in a format such as XML or JSON. It doesn't need to be dictionary
driven or marked-up; Arrays of arrays will work just fine.

Don't encourage people to just pull data from MV files and manipulate
it in a MV type fashion using their chosen language. Use the power of
a MV system and keep the business logic there.

Most MV products have libs that will let you call subroutines from
other languages, so you're already half way there. Add the interfaces
for popular technologies such as PHP, and Bob's your uncle.

--
Kevin Powick

If you don't want to read the whole thread, I refer to Tony's
Tony, you hit the nail right on the head. I use MV like file handling with
VB in almost exactly the same way but not quite. I have had to create the
classes in VB to Locate , and so forth. But they are surprisingly few and
surprisingly simple. Now I use MV in its simplest form - that is, within
the Contacts Master File the phone numbers coupled with the primary use of
each number and the order in which to try when you call are nested and
related. I don't use the classic Order Heading, Order Line but there is no
real need to do so. Note that I am not using any DB Manager, just a simple
file handler with a simple hash for Item ID. Works very fast for relatively
small files. Probably would not scale well at all to files with hundreds of
thousands or millions of entry. But using your approach with a QM or jBase
back end it should scale beautifully. And - sorry to say this Martin - it
looks like one license would be all that is needed for any number of users.
Someone, and I'm thinking of Martin now, could write a specialized version
that specifically supports only files and has no TCL per se.
BobJ

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

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

But there are millions of programmers who don't know how to use the Power
and only thousands who do. So if Tony, or anyone, is going to make it pay
then it seems he would be better advised to address the millions rather than
the thousands.
BobJ

On Mar 14, 8:35*am, "RJ" <nob... (AT) nowhere (DOT) com> wrote:

Emulating VM inside an external programming language will do little to
encourage those people to work inside MV. More likely, it will result
in their MVDB being nothing more than a simple data repository, and
these funky language bindings a necessary evil. The true power of MV
lies in its multivalue file structure and the integration of BASIC at
the database level.

You are not going to retrain millions of RDBMS people to start
thinking of database interaction in terms of MV constructs and
syntax. They certainly aren't going to use such syntax to talk to
relational databases as Tony eluded to with the idea of these MV type
language bindings adapted to SQL type databases. Add to this that in
a multi-tier / MVC world, one really shouldn't be opening files and
reading records at the user interface level.

However, if to manipulate and work with MV you get these same people
to work inside of MV, you expose them to the true strength of the
platform and leave the heavy lifting where it should be.

Having said this, I doubt the concept would fly. Many RDBMS have
powerful concepts such as views, functions, triggers, RI, and stored
procedures. Yet, you would be surprised how many developers do not
use or even really understand them. -- Even those that only target one
SQL platform.

Also, don't forget that many MV products already have exactly the
language bindings being talked about. jBASE, QM, D3, Universe,
Reality. They've all had them for a long time. Even though they are
MV platform specific, they have done little to convert the great
unwashed to MV. All they have done is allow MV developers to use many
of the tools and technologies available to the general development
world. That is not likely to change anytime soon.

--
Kevin Powick

Kevin Powick wrote:

I have experience interfacing Ruby on Rails to uniData using webs
services that return XML and JSON both. This is Active Resource,
not Active Record.

I'm happy with Active Resource: job security for me. But the RoR
boys want teh Active Resource.

--
frosty

We produced an API for PHP a few months ago. Using open source PHP-
Java Bridge
we were able to hook up this into our U2WebLink(tm) middle-ware in a
few days. You can
call any subroutine, call and VOC command, and additionally you have
the ability to use
JSON in sending data from Unidata or Universe to PHP. You can call
our own subroutines
that do reading, writing and deleting. These routines automatically
do logging and audit
of all transaction. Built-in to our middle-ware is even replication
that can be local or remote.

We have written a Java connection manager in U2WebLink(tm) and it
handles the interactions
with U2 so you don't have too. Our middle-ware has been running for
many years now handling
millions of hits per month without out a burp.

Stop chewing you cud and check out the sample code at www.u2logic.com/php.html.
You can then purchase this utilities from Google Checkout at
www.u2logic.com/tools.html.

Regards,
Doug

On Mar 14, 1:14*pm, "dave... (AT) gmail (DOT) com" <dave... (AT) gmail (DOT) com> wrote:

Purchase? As in spend money? You do realized you've posted in CDP,
don't you?

--
Kevin Powick

Kevin Powick wrote:
An API will be used by two kinds of people, those familiar with MV,
and those who are not. Every MV library already supports the common
environment features for accounts, files, items, attributes, callable
subroutines and statement execution. Any library that doesn't support
the common features will be considered unusable by people who use it
every day - not good for marketing. So the API must (and does)
include these basics, and anyone not familiar with MV can mix and
match from the toolkit as they wish. Each language binding can
support am/vm/svm positioning through arrays (non-MV people don't need
to call these attributes) and dict items can be used to define a
primary view for named fields. In other words, there shouldn't be too
much, but not too little either.


I haven't emphasized using BASIC but, as above, that's already in the
API.

I believe a new offering like this should give people a freedom of
choice as to where functionality is placed. You won't get new buy-in
with instant mandates that people learn a new language (BASIC) or
environment (everything else in MV). People can write code with the
MVC pattern (or Strategy or any other but let's not go there) or they
can write plain ol' inline code mixing UI with rules. PHP, Perl, and
Classic ASP/VB notoriously mix UI and rules, and developers shouldn't
be compelled to move their rules to a different environment. So with
MVFile (or MVTable), MVItem, etc, they can put their rules into the UI
or lower tiers, or they can choose to implement their rules in BASIC
when they're ready - as many RDMS developers choose to migrate from
queries to stored procedures, and then some go further to call Java,
C++, or managed .NET code from their SPs.

T

Kevin Powick wrote:

But wouldn't it be a treat for MV programmers to prototype their PHP
or Java code against MV, because that's _their_ comfortable starting
place, and then to use the same code against relational databases?
For example:

account = New MVAccount(dbms,"Accounting");
file = account.FileOpen("Customer");
item = file.Read("123");
item("Name") = "Kevin";
file.Write(item);

There's no reason why that code cannot operate unchanged with "dbms"
equal to QM, Oracle, Reality, Caché, Postgres, Universe, MySQL, or the
name of a CSV file.

As to retraining millions of people, I have no such delusions. But to
non-MV people this is simply another platform and another way to
access databases - it's a new choice that they didn't have before and
it remains to be seen whether or not they'd take it. In just the last
few years we've seen rapid takeup of completely new languages and
paradigms like Ruby, IronPython, LINQ, and ORM frameworks. People
adapt in the "real" world much faster than yer average Pickie.


Granted but everyone has their own coding style and I'm guessing about
70% of the world's developers aren't using MVC or recognizing any
other patterns yet. You have a cup holder in your car even though you
shouldn't be drinking and driving - the tools and options must be
there so that people can choose how and where to use them.


Full agreement - but this is more like step two or three. Step one is
to get them started using tools familiar to them. The docs will show
them the rabbit hole goes deeper but they won't be pushed in. They
can jump in when they've seen they can manipulate data from outside
but that it will be better if they do it from inside (with BASIC).


Well, the relational model is successful despite the volume of RDBMS
features that aren't used. And as they say, 80% of Excel users only
use 20% of the features. You don't stop yourself from offering a rich
platform because it's too rich. The documentation and community
support need to be as rich as the platform so that people will
understand what's available so that they can make valid choices.


All of those tools were created for two linked purposes: First, so
that MV people could branch out to other languages without having to
move away from MV. Second, so that a MV shop could hire someone with
other language skills to work with the platform.

I disagree that language bindings were created for the "great
unwashed". Barring short-term, limited-effort campaigns, virtually
none of the MV DBMS providers (Revelation a big exception) have done
any marketing to the outside world to get people to use MV products.
You're not going go to a Java developer's conference and see a booth
for jBase International. You will probably see InterSystems at such a
conference, but they won't be talking about using MV extensions in
Caché. I'm baffled by these MV DBMS companies who are obviously
looking for ways to generate revenue but they're mired in the same
self-defeating apathy as their developer base, believing that they
can't sell MV to a relational world. The most positive thing I saw at
the TigerLogic conference in November was Susie Siegesmund and Rick
Koe talking about MV in a greater context, but, with all due respect,
I don't think they, nor their teams, or any other DBMS providers have
enough faith to really market MV to new audiences.


Agreed. This is why I believe the only way to get anything done is
for the MV user/developer community to do it, independent of, perhaps
even in spite of, the DBMS providers.

T