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.
"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.
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....
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:
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.
> "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.
> 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....
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:
> 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:
> 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.
> > "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.
> > 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....- Hide quoted text -
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!"
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!
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.
> 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!
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.
<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.
> > 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!
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. _____________
