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. _____________
> 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.
> _____________
> 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....
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:
> 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....
[mailto:enterprise-web-developer-community@googlegroups.com] On Behalf Of
Bill Ackerman
Sent: 22 August 2008 15:53
To: Enterprise Web Developer Community
Subject: [EWD:278] Re: Schemaless and hierarchical databases
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:
> 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....
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.
On Aug 22, 12:18 pm, George James <Geor...@georgejames.com> wrote:
> [mailto:enterprise-web-developer-community@googlegroups.com] On Behalf Of
> Bill Ackerman
> Sent: 22 August 2008 15:53
> To: Enterprise Web Developer Community
> Subject: [EWD:278] Re: Schemaless and hierarchical databases
> 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:
> > 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....
> 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....
> 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.
> On Aug 22, 12:18 pm, George James <Geor...@georgejames.com> wrote:
> > [mailto:enterprise-web-developer-community@googlegroups.com] On Behalf Of
> > Bill Ackerman
> > Sent: 22 August 2008 15:53
> > To: Enterprise Web Developer Community
> > Subject: [EWD:278] Re: Schemaless and hierarchical databases
> > 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:
> > > 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....
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:
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
rtweed 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 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....
> 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:
> 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
> rtweed 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 -
> 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.
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:
> 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 -
> ... 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++ :))
> > ... 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++ :))
> On Oct 4, 2:38 pm, JohnLeo Zimmer <johnleo...@gmail.com> wrote:
> > 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++ :))
|
