Schemaless and hierarchical databases

[rtweed]

Isn't it ironic that whilst ISC have spent the last 10 years
desparately trying to hide that "old-fashioned" underlying MUMPS
database and add a whole layer of object orientation and schema to
make it palatable to the marketplace, the rest of the world is
increasingly realising that schema-less and hierarchical databases are
actually what they're looking for in the modern, internet-focused
world.

Try Googling "schemaless database" and you'll very quickly find out
about new databases such as Poseidon (http://www.brainwavelive.com/
developers/applications/poseidon-database.html) and Amazon's SimpleDB
(http://www.amazon.com/gp/browse.html?node=342335011). Indeed how
even more ironic to see this quote in http://www.satine.org/archives/2007/12/13/amazon-simpledb/
:

"Schemaless - major cool factor for me here; items are little hash
tables containing sets of key, value pairs"

So, far from being old-fashioned and something that turns people away,
the inherent schemaless nature of MUMPS is now something that can be
promoted as a cool feature! My prediction is that schemaless is soon
to become the new schema!


How about hierarchical databases? You'll see less about this when you
Google it, apart from sad arcticles explaining the bizarre lengths
folks have to go to in order to store hierarchical data in relational
databases. However, check out Google BigTable and you'll find a new
implementation of the hierarchical database model, and of course,
because it bears the Google name, is automatically deemed to be cool!

The hierarchical database comes into its own for storage of the
naturally hierarchical structure of XML and, more recently, JSON.
Check out http://www.rpbourret.com/xml/UseCases.htm for more info on
so-called Native XML Databases.

As both our own eXtc and EWD products have shown, the projection of
the W3C XML DOM is so straightforward and natural that you'd have
thought W3C had designed it to use a MUMPS engine! As a persistent
storage engine for data exposed and transported as JSON strings, again
the MUMPS model is a perfect fit, and JSON is one of today's super hot
technologies.

So why am I harping on about this? Because here we all are using a
technology (in both Cache and GT.M) that, far from being something you
should be apologetic about and trying desparately to hide, you should
be shouting about from the hill-tops. What you've been taking for
granted for years, the rest of the world is now starting to realise is
exactly what they need.

Of course, at M/Gateway we've been saying this for years, eg
http://gradvs1.mgateway.com/download/extreme1.pdf.

So here's the thing: the MUMPS database is a schemaless hierarchical
database. Both at once! How cool is that?!! Imagine what you could
do with that?! Answer: stuff that the rest of the mainstream can only
dream about but drool at the idea of being able to do. And MUMPS is a
tried and tested technology, not some "new kid on the block" barely
out of a start-up's R&D labs.

So now you know how cool a technology it is, get out there and tell
the world about it....

[rtweed]

And here's another, this time from the Apache folks:

http://incubator.apache.org/couchdb/

Note the role of Javascript and JSON!

and ObjectKitchen:

http://code.google.com/p/objectkitchen/source/browse/branches/network-branch/readme.txt?r=40

..and strokeDB:

http://www.infoq.com/news/2008/04/distributed-db-strokedb

...and dovetailDB:

http://code.google.com/p/dovetaildb/


One reason these people are re-inventing the wheel instead of using a
tried and tested MUMPS engine as the basis of this kind of thing is
probably because MUMPS doesn't appear in Google when you search for
"schemaless database". That shouldn't be too difficult to change!



And check out the various ramblings of various people such as:

http://syntacticsirup.blogspot.com/2007/01/tuplesoup-part-1.html

http://www.berbs.us/search?query=schemaless

http://www.productionscale.com/home/2007/8/11/getting-rid-of-the-relational-database.html




Oh and of course one thing I didn't note in my first posting - with
GT.M we have a free OpenSource version of the schema-less,
hierarchical database. Even cooler still !!

On 16 Aug, 11:19, rtweed <rob.tw...@gmail.com> wrote:
> Isn't it ironic that whilst ISC have spent the last 10 years
> desparately trying to hide that "old-fashioned" underlying MUMPS
> database and add a whole layer of object orientation and schema to
> make it palatable to the marketplace, the rest of the world is
> increasingly realising that schema-less and hierarchical databases are
> actually what they're looking for in the modern, internet-focused
> world.
>
> Try Googling "schemaless database" and you'll very quickly find out
> about new databases such as Poseidon (http://www.brainwavelive.com/
> developers/applications/poseidon-database.html) and Amazon's SimpleDB
> (http://www.amazon.com/gp/browse.html?node=342335011). Indeed how

> even more ironic to see this quote inhttp://www.satine.org/archives/2007/12/13/amazon-simpledb/

> :
>
> "Schemaless - major cool factor for me here; items are little hash
> tables containing sets of key, value pairs"
>
> So, far from being old-fashioned and something that turns people away,
> the inherent schemaless nature of MUMPS is now something that can be
> promoted as a cool feature! My prediction is that schemaless is soon
> to become the new schema!
>
> How about hierarchical databases? You'll see less about this when you
> Google it, apart from sad arcticles explaining the bizarre lengths
> folks have to go to in order to store hierarchical data in relational
> databases. However, check out Google BigTable and you'll find a new
> implementation of the hierarchical database model, and of course,
> because it bears the Google name, is automatically deemed to be cool!
>
> The hierarchical database comes into its own for storage of the
> naturally hierarchical structure of XML and, more recently, JSON.

> Check outhttp://www.rpbourret.com/xml/UseCases.htmfor more info on

> so-called Native XML Databases.
>
> As both our own eXtc and EWD products have shown, the projection of
> the W3C XML DOM is so straightforward and natural that you'd have
> thought W3C had designed it to use a MUMPS engine! As a persistent
> storage engine for data exposed and transported as JSON strings, again
> the MUMPS model is a perfect fit, and JSON is one of today's super hot
> technologies.
>
> So why am I harping on about this? Because here we all are using a
> technology (in both Cache and GT.M) that, far from being something you
> should be apologetic about and trying desparately to hide, you should
> be shouting about from the hill-tops. What you've been taking for
> granted for years, the rest of the world is now starting to realise is
> exactly what they need.
>

> Of course, at M/Gateway we've been saying this for years, eghttp://gradvs1.mgateway.com/download/extreme1.pdf.

[seanatc...@googlemail.com]

I agree, the topic of schema free databases is very pertinent to
today’s web application requirements. And as you say mumps is not some
"new kid on the block" trying to solve this problem.

Relational schemas or class based development can constrain more than
data, they can also constrain free flow development.

As mumps developers we also understand the pit falls of schema free
databases, something else the "new kids" have to experience firsthand.

In fact what we need is not a "schema free" database, but a "free flow
schema" database. A free flow schema that promotes free flow
development, call it an adaptive or semantic schema. Add
to that a layer of abstraction that overcomes the pit falls of raw
global development.

I see this abstraction not as classed based development but as object
based development in a similar way that JavaScript objects are freely
written. These objects auto inherit persistent functionality and
constructors to serialise and de-serialise object data such as HTML
forms, JSON and XML.

In "design mode" the developer can design and code freely. Once this
stage is completed constraints can then be optionally applied to the
semantic schema. In "run time mode" these constraints assure the
quality of data and help protect against security issues such as data
injection.

The semantic schema is constructed with information gathered either by
the compiler or by the data engine during "design mode". Consider the
following example...

FooBar.Person
{
Save()
{
Set person=FooBar.Person(%session("person"))
Set person.Updated=Lib.Dates.Now()
Set person.Sex=
$Select(Person.Sex="Male":"M",Person.Sex="Female":"F",1:"U")
Set status=person.save()
Write status
}
ToJSON()
{
Set person=FooBar.Person.Open(%session("person.id"))
Set person.Age=Lib.Dates.Age(person.dob) //this could be moved
into the semantic schema
person.Salary.Hide() //hide this information from general
requests
Write person.ToJSON()
}
}

where %session("person") contains either a simple name value list of
person properties or maybe a more complex nest of person related
objects.

First off lets assume that EWD is being used as the web engine,
%session will therefore compile down to $$getSessionValue^%zewdAPI. On
an EWD page an action will call FooBar.Person.Save()
which will post the blob of person data, this could be html form data,
JSON or XML. The constructor recognises the type and constructs a run
time object. We can manipulate that object
before saving it to the database. The save() method abstracts all the
global saves, transactions and error handling.

At compilation time the compiler doesn't know much about the Person
object. But once the code is executed during "design mode" the data
engine can profile the person object and add
information to the semantic schema. This allows the developer to
change the form object without making changes up stream.

Whilst the semantic schema could be used to drive a SQL engine such as
GT.m's PIP engine I see a much more simple "for each object where..."
syntax. This could be used to spin through data
or output data as a certain format type. For example...

FooBar.Person
{
BySurnameAsArray(surname) As JSArray
{
for each person in FooBar.Person where person.surname=surname
{
select person.surname as "Surname", person.forename as
"Forename", person.address.postcode as "Post Code" //similar to a
result set
}
}
BySurnameAsJson(surname) As JSON
{
for each person in FooBar.Person where person.surname=surname
{
select person //this version outputs a collection of person
objects, more sophisticated than a result set
}
}
}

I would take this extended mumps language further and add some of
these additional features

1. Adaptive indexing
2. Automatic detection and adaptive indexing of object relationships
(completely do away with joins in queries)
3. Integrated RAD studio with features such as auto complete of
semantic objects and inteligent warnings
4. The ability to project class based languages into semantic objects,
such as Cache, C# and Java. For instance Cache data could be injected
into GT.m. Or in reverse mumps could take
advantage of the powerful libraries in .NET and Java by projecting
semantic objects as C# / Java data proxy objects.

The bottom line is that its easy to see how Mumps already has the
flexibility and more importantly the speed to handle this type of
functionality. Trying to achieve the same functionality within
relational databases is just one more layer of complexity to add to
the object-relational impedance. Which just adds up to sluggish,
costly and difficult to scale applications.

Whilst Cache could provide a platform for this functionality it will
never fit into the low cost web application model.

Thankfully GT.m is open source and is just begging for this type of
solution to be developed for it. If a non-scalable solution such as
ruby on rails can go mainstream then what could a powerful and
scalable GT.m / EWD / Extended Mumps solution do for the web
development industry?

Mumps is not dead!

Sean.

On 16 Aug, 14:03, rtweed <rob.tw...@gmail.com> wrote:
> And here's another, this time from the Apache folks:
>
> http://incubator.apache.org/couchdb/
>
> Note the role of Javascript and JSON!
>
> and ObjectKitchen:
>

> http://code.google.com/p/objectkitchen/source/browse/branches/network...

>
> ..and strokeDB:
>
> http://www.infoq.com/news/2008/04/distributed-db-strokedb
>
> ...and dovetailDB:
>
> http://code.google.com/p/dovetaildb/
>
> One reason these people are re-inventing the wheel instead of using a
> tried and tested MUMPS engine as the basis of this kind of thing is
> probably because MUMPS doesn't appear in Google when you search for
> "schemaless database".  That shouldn't be too difficult to change!
>
> And check out the various ramblings of various people such as:
>
> http://syntacticsirup.blogspot.com/2007/01/tuplesoup-part-1.html
>
> http://www.berbs.us/search?query=schemaless
>

> http://www.productionscale.com/home/2007/8/11/getting-rid-of-the-rela...

> > the world about it....- Hide quoted text -
>
> - Show quoted text -

[K.S. Bhaskar]

Thank you, Rob and Sean for giving me ideas on how to reposition GT.M
in a way that will benefit all of us - and importantly, those using
it. In GT.M, we have a proven, industrial-strength, typeless / schema-
free / schema-less / adaptive schema database with full ACID (Atomic,
Consistent, Isolated, Durable) transaction semantics. With its
ability to set up logical multi-site configurations that can provide
continuity of business not only in the face of unplanned events (like
system crashes) but also planned events (like system, application and
schema upgrades - these are harder, because in a world that needs
"five nines" availability, the application that can be upgraded in an
enterprise-wide production environment in 5 minutes has not been built
yet). Also in the new world order, open source licensing is
important.

Importantly, even though the new world order may be schemaless, there
are still applications that require schemas. The beauty of MUMPS is
that with layered software, one can take that same schema and present
it differently to different consumers (a report generating program, a
visualizer, a mash-up, etc.).

Useful things don't die - they just become useful in new ways. London
was a long established when Julius Caesar came to visit. Although he
would not recognize it if he were to return today, it continues to
thrive, and has evolved continuously. "MUMPS is dead. Long live
MUMPS!"

Regards
-- Bhaskar

[rtweed]

The fact that we have, in GT.M,. a free, open source Mumps engine,
gives the community a great opportunity: to take the initiative and
develop the kind of modern value-added facilities that have
proliferated for other environments but, critically, ensure that Mumps
can be shown to naturally meet and fit with the new-found requirements
of the mainstream.

Why wait for a vendor to create these facilities (to meet their
agenda) when we should be able to implement them ourselves and
distribute them for free?

Sean has outlined some areas. Let me suggest some others:

- a Mumps plug-in for Eclipse. Not a far cry from the Serenji editor,
but using the darling of the mainstream world instead of a proprietary
technology.

- The big one in my view is the integration of Javascript and
Javascript objects with Mumps, to provide persistence for Javascript
objects and allow Javascript to be a scripting language for Mumps.
Javascript's dynamic, non-class-based objects are a natural fit for a
Mumps engine, allowing objects to be defined and extended on the fly.
The fact that Javascript Objects are a projection of Arrays also is a
natural fit, eg

person.address.line1 = "1 The Street"

is synonymous with

person["address"]["line1"] = "1 The Street"

and so you can iterate through a level in the object using "for in",
eg

for (line in person.address) {
var text = person.address[line] ;
...etc
}

Something very similar, then, to Sean's suggestion and something that
should be easy to map to Mumps!

Mapping to and from JSON would then be an obvious extension of this
integration of Javascript and Mumps.

That's just two ideas that come to mind. I'm sure there are many
other places where Mumps capabilities can be made to naturally
converge with mainstream requirements.

It seems to me that with the world now waking up to the value of the
very features inherent in Mumps (the same features that have been
previously used as the reason *not* to use Mumps!), as a community
we've never had a better chance to get Mumps out there and recognised
as a hot technology for underpinning the modern world.

It's in our hands to grasp that opportunity, and this time we can't
and shouldn't sit back and expect a vendor to do all the work. No
more crying into our beer mugs about Mumps being the IT world's best-
kept secret. It's up to us all to make it happen! We're doing our
bit with EWD, positioning Mumps as the best environment for web
application development. Come on and help the cause!

[David Whitten CTO WorldVistA]

Sean has outlined some areas. Let me suggest some others:

- a Mumps plug-in for Eclipse. Not a far cry from the Serenji editor,
but using the darling of the mainstream world instead of a proprietary
technology.

Why re-invent this?
Joel Ivy of the VA (from Seattle) already had done it and made it available.

David

[rtweed]

Interesting - how does one find out more about this?

Therein is one of the problems. There's lots of stuff people have
done with Mumps that nobody knows about. If it's stuff that makes
Mumps work with the mainstream then we need to get it known about, and
these days that means getting this kind of stuff to come up on Google
at the right times.

Rob


On 19 Aug, 20:15, "David Whitten CTO WorldVistA"

<whit...@worldvista.org> wrote:
> Sean has outlined some areas. Let me suggest some others:
>
> - a Mumps plug-in for Eclipse. Not a far cry from the Serenji editor,
> but using the darling of the mainstream world instead of a proprietary
> technology.
>
> Why re-invent this?
> Joel Ivy of the VA (from Seattle) already had done it and made it available.
>
> David
>

[K.S. Bhaskar]

On 08/19/2008 03:15 PM, David Whitten CTO WorldVistA wrote:
>
> Sean has outlined some areas. Let me suggest some others:
>
> - a Mumps plug-in for Eclipse. Not a far cry from the Serenji editor,
> but using the darling of the mainstream world instead of a proprietary
> technology.
>
> Why re-invent this?
> Joel Ivy of the VA (from Seattle) already had done it and made it
> available.
>

[KSB] Dave, I was at the presentation where Joel spoke of this. Do you
know where it is posted? Thanks.

Regards
-- Bhaskar

_____________

The information contained in this message is proprietary and/or confidential. If you are not the
intended recipient, please: (i) delete the message and all copies; (ii) do not disclose,
distribute or use the message in any manner; and (iii) notify the sender immediately. In addition,
please be aware that any message addressed to our domain is subject to archiving and review by
persons other than the intended recipient. Thank you.
_____________

[Marty Mendelson]

I believe this was at the meeting at U.W. two years ago. Indeed, I
have a disk at home that Joel gave out - I'll check when I get back
there.

Marty Mendelson

[rtweed]

You may be interested in this joint effort:

http://www.slideshare.net/george.james/mumps-the-internet-scale-database-presentation/

Enjoy! :-)

On 16 Aug, 11:19, rtweed <rob.tw...@gmail.com> wrote:

> Isn't it ironic that whilst ISC have spent the last 10 years
> desparately trying to hide that "old-fashioned" underlying MUMPS
> database and add a whole layer of object orientation and schema to
> make it palatable to the marketplace, the rest of the world is
> increasingly realising that schema-less and hierarchical databases are
> actually what they're looking for in the modern, internet-focused
> world.
>
> Try Googling "schemaless database" and you'll very quickly find out
> about new databases such as Poseidon (http://www.brainwavelive.com/
> developers/applications/poseidon-database.html) and Amazon's SimpleDB
> (http://www.amazon.com/gp/browse.html?node=342335011). Indeed how

> even more ironic to see this quote inhttp://www.satine.org/archives/2007/12/13/amazon-simpledb/

> :
>
> "Schemaless - major cool factor for me here; items are little hash
> tables containing sets of key, value pairs"
>
> So, far from being old-fashioned and something that turns people away,
> the inherent schemaless nature of MUMPS is now something that can be
> promoted as a cool feature! My prediction is that schemaless is soon
> to become the new schema!
>
> How about hierarchical databases? You'll see less about this when you
> Google it, apart from sad arcticles explaining the bizarre lengths
> folks have to go to in order to store hierarchical data in relational
> databases. However, check out Google BigTable and you'll find a new
> implementation of the hierarchical database model, and of course,
> because it bears the Google name, is automatically deemed to be cool!
>
> The hierarchical database comes into its own for storage of the
> naturally hierarchical structure of XML and, more recently, JSON.

> Check outhttp://www.rpbourret.com/xml/UseCases.htmfor more info on

> so-called Native XML Databases.
>
> As both our own eXtc and EWD products have shown, the projection of
> the W3C XML DOM is so straightforward and natural that you'd have
> thought W3C had designed it to use a MUMPS engine! As a persistent
> storage engine for data exposed and transported as JSON strings, again
> the MUMPS model is a perfect fit, and JSON is one of today's super hot
> technologies.
>
> So why am I harping on about this? Because here we all are using a
> technology (in both Cache and GT.M) that, far from being something you
> should be apologetic about and trying desparately to hide, you should
> be shouting about from the hill-tops. What you've been taking for
> granted for years, the rest of the world is now starting to realise is
> exactly what they need.
>

> Of course, at M/Gateway we've been saying this for years, eghttp://gradvs1.mgateway.com/download/extreme1.pdf.

[Bill Ackerman]

Hi All,
I have and do use the M/Eclipse interface developed by Dr. Joel Ivey.
It is great! I have used it for over a year and give him constant
feedback.

There are some issues:
1) It is that it is designed to work only with a "VistA" VA system.
You need the VA Kernel, Fileman, Package Manager and other VA
pieces to make it work.
2) Dr. Ivey has been developing this for a LONG time and has not been
able to dedicate a lot of time to it.
3) It is RAW in some places and fantastic in other places.

If you want to avoid Cache Cube "slowing down"/"running" on your
desktop, or want to provide a developer with access to routines and
data with out giving him/her "M Prompt" or "OS" level access, this is
the perfect tool. I would suggest that we as a group see if we can
pick up from him the latest copy and see if we can make it a tool that
can work with VistA and Non-VistA implementation of Mumps/GTM/Cache.

The way I see it is, we need a flexible tool that is not dependent on
anything other than M. Yes, what Dr. Ivey has done it fantastic and
works very well with in the VistA system. But, we need to look at the
larger picture and have a tool that will work with any Mumps based
system. I am sure that Dr. Ivey will welcome any one with a Java
background that is willing to work in this project.

Regards,

Bill Ackerman

On Aug 22, 6:01 am, rtweed <rob.tw...@gmail.com> wrote:
> You may be interested in this joint effort:
>

> http://www.slideshare.net/george.james/mumps-the-internet-scale-datab...

[George James]

How is it licensed? GPL? Public Domain?


George James Software
www.georgejames.com

[Bill Ackerman]

George,
Since it is part of the VA Kernel, it is public domain. That being
said, it hs not been released to the public domain just yet. But, if
we can get a group that would be willing to work with Dr. Ivey and
help move it forward I am sure that we can get a copy for a "Select
group". Currently, it has 2 componits, one Eclipse Plug-in and one
Kids ("K"ernel "i"nstallation and "d"istribution "s"ystem) Build. It
is easy to install and easy to implement.
later...
Bill A.

[rtweed]

Slideshare have made this one of their featured presentations which is
very pleasing!

On 22 Aug, 12:01, rtweed <rob.tw...@gmail.com> wrote:
> You may be interested in this joint effort:
>

> http://www.slideshare.net/george.james/mumps-the-internet-scale-datab...

[rtweed]

If anyone gets involved in this Eclipse initiative, it would be great
if you could update us all on progress, perhaps in a thread in this
group.

[Caoimhghin]

We use Mumps in our Information Storage and Retrieval
course at the University of Northern Iowa. It is an ideal
platform in which to explore large scale applications
for classifying and categorizing textual information.
We also use in it a number of bioinformatics projects
where, likewise, the global array data base is well
suited to the problem at hand.

In our version of Mumps, which is similar but not
fully identical to the old standard, we've added
many functions such as Smith-Waterman sequence
matching, Perl pattern matching, document vector
correlation functions (Cosine, Jaccard, et al.) as well
as Boyer-Moore-Gosper and n-gram based searching.
We see our system as a platform to explore new applications
and ideas. Our version is free, written in C++, runs
on Linux, Cygwin and Windows (some restrictions
apply) and is GPL licensed. See:

http://www.cs.uni.edu/~okane

The above linked page has links to the Mumps download,
a C++ class library to enable Mumps-like file and
string access from C++ programs and a link to our
online text book in information retrieval, written
in Mumps.

Our built-in global array data base has a theoretical
upper limit of 256 terabytes and we've recently installed
a feature that permits storage of global arrays in the
the PostgreSql relational database system as well
as queries of in same.

We've also implemented full shell command execution
by means of a "shell" Mumps command. Our system
also supports Mumps scripting for cgi-bin active server
pages and an "html" command that permits Mumps
expressions to be embedded into HTML statements.

We treat Mumps as a scripting language. Our students
find it intriguing for certain applications and when surveyed
by others faculty in other courses, they consistently rank
Mumps as one of their favorites.

An all-purpose programming language Mumps is not.
As a specialized language in the category of PHP,
Perl, et al., I think it has a strong future.

Kevin O'Kane
University of Northern Iowa
Cedar Falls

[Torkild]

I do enjoy this thread,
Will we see a change @ISC to allow for more M words ???
(We should be so lucky!)

For the latest thread, I have downloaded it ready to be played with
when time allows me.
Looking forward to check it out.

Torkild

> > even more ironic to see this quote inhttp://www.satine.org/archives/2007/12/13/amazon-simpledb/

> > :
>
> > "Schemaless - major cool factor for me here; items are little hash
> > tables containing sets of key, value pairs"
>
> > So, far from being old-fashioned and something that turns people away,
> > the inherent schemaless nature of MUMPS is now something that can be
> > promoted as a cool feature!  My prediction is that schemaless is soon
> > to become the new schema!
>
> > How about hierarchical databases?  You'll see less about this when you
> > Google it, apart from sad arcticles explaining the bizarre lengths
> > folks have to go to in order to store hierarchical data in relational
> > databases.  However, check out Google BigTable and you'll find a new
> > implementation of the hierarchical database model, and of course,
> > because it bears the Google name, is automatically deemed to be cool!
>
> > The hierarchical database comes into its own for storage of the
> > naturally hierarchical structure of XML and, more recently, JSON.

> > Check outhttp://www.rpbourret.com/xml/UseCases.htmfor  more info on

> > so-called Native XML Databases.
>
> > As both our own eXtc and EWD products have shown, the projection of
> > the W3C XML DOM is so straightforward and natural that you'd have
> > thought W3C had designed it to use a MUMPS engine!  As a persistent
> > storage engine for data exposed and transported as JSON strings, again
> > the MUMPS model is a perfect fit, and JSON is one of today's super hot
> > technologies.
>
> > So why am I harping on about this?  Because here we all are using a
> > technology (in both Cache and GT.M) that, far from being something you
> > should be apologetic about and trying desparately to hide, you should
> > be shouting about from the hill-tops.  What you've been taking for
> > granted for years, the rest of the world is now starting to realise is
> > exactly what they need.
>
> > Of course, at M/Gateway we've been saying this for years, eg
> >http://gradvs1.mgateway.com/download/extreme1.pdf.
>
> > So here's the thing: the MUMPS database is a schemaless hierarchical
> > database.  Both at once! How cool is that?!!  Imagine what you could
> > do with that?!  Answer: stuff that the rest of the mainstream can only
> > dream about but drool at the idea of being able to do.  And MUMPS is a
> > tried and tested technology, not some "new kid on the block" barely
> > out of a start-up's R&D labs.
>
> > So now you know how cool a technology it is, get out there and tell

[Toucan]

Hi Rob - another excellent post and hopefully the world will get to
hear about it. /Tony

p.s. see link below for another article that may be of interest.

Understanding HBase and BigTable
http://java.dzone.com/news/understanding-hbase-and-bigtab

On 16 Aug, 11:19, rtweed <rob.tw...@gmail.com> wrote:

[Fernando Telesca]

Hi all,

This is really a thread to be permalinked. I´d suggest that, as google
groups seems to be the ideal HQ for MUMPS "face-lift", you could all
update your google profiles in order to weight the posted content
(here, Hardhats, comp.lang.mumps etc...). Also I think that, if at
some point in the past MUMPS community choose to change its name to M
(for very known reasons), we could embrace this designation to
identify this next step of MUMPS evolution you are discussing here. It
could be M++ :))

Regards,

Fernando

On 2 out, 18:05, Toucan <tou...@spuddy.mew.co.uk> wrote:
> Hi Rob - another excellent post and hopefully the world will get to
> hear about it.  /Tony
>
> p.s. see link below for another article that may be of interest.
>

> Understanding HBase and BigTablehttp://java.dzone.com/news/understanding-hbase-and-bigtab

>
> On 16 Aug, 11:19, rtweed <rob.tw...@gmail.com> wrote:
>
>
>
> > Isn't it ironic that whilst ISC have spent the last 10 years
> > desparately trying to hide that "old-fashioned" underlying MUMPS
> > database and add a whole layer of object orientation and schema to
> > make it palatable to the marketplace, the rest of the world is
> > increasingly realising that schema-less and hierarchical databases are
> > actually what they're looking for in the modern, internet-focused

> > world.- Ocultar texto entre aspas -
>
> - Mostrar texto entre aspas -

[JohnLeo Zimmer]

Fernando Telesca wrote:
>
> ... Also I think that, if at

> some point in the past MUMPS community choose to change its name to M
> (for very known reasons), we could embrace this designation to
> identify this next step of MUMPS evolution you are discussing here. It
> could be M++ :))
>

M++

(or perhaps MMR, MUMPS + MEASLES + RUBELLA)

[rtweed]

Now here's an interesting (and, for once, a positive) blog from
someone who's discovered Mumps:

http://mad-computer-scientist.com/blog/?p=79

Rob

[wolfkoelling]

Yes but then he is mad, by his own admission.

Wolf

> > (or perhaps MMR,  MUMPS + MEASLES + RUBELLA)- Hide quoted text -