From: K.S. B. <k.b...@sa...> - 2000-11-19 13:01:19
|
Comments embedded. -- Bhaskar -----Original Message----- From: Emiliano To: san...@li... Sent: 11/18/00 2:24 PM Subject: [Sanchez-gtm-core] Mumps comments Just some of the stuff I found while reading up on Mumps: >>M has many good points: high productivity, low hardware requirements, good scalability. But M also has some weaknesses: low transaction reliability, character-based screens, poor integration with other environments, and few development tools. [Thomas C. Salander, M Computing, June 1994, p.74] M is a lousy language with one great data type. [Steve J. Morris]<< Do these still apply? [KSB] Don't believe everything you read, including my e-mails. 8-] The above may be true of the other MUMPsen, but not to GT.M. GT.M is the database of record for many large banks. For example (since you may be from Holland), you may well already have your bank balance in a GT.M database, since ING is rolling Sanchez's PROFILE/Anyware application out worldwide! A transaction processing engine that doesn't deal with full ACID properties is not a transaction processing engine. Do we have bugs? Yes. Do Oracle, DB2, and SQL Server have bugs? [The answer depends on whether you talk to their engineers and users or their marketing and sales people.] GT.M does provide character based screens, just like other implementations. The user interface for GT.M is entirely character based. However, we use GT,M at Sanchez to run back end server processes for banking applications, and those beautifully countoured buttons with textured shading are more important at the front end on the user's PC. At Sanchez, the banking engine is a server process (actually, many server processes, since GT.M scales up very well in SMP environments, especially if you use transaction processing features) that receive messages (e.g., transfer $100 from account x to account y) via middleware from front ends which could be ATMs, browsers, tellers, cellular phones, etc. They process these messages and reply via messages. The back end is designed to be always on, and when logical dual site is in use, to be always available, even if a terrorist blows up a data center, or, more likely, when a major upgrade requires a database schema change. Other MUMPSen may not integrate into the host OS environment. GT.M is a compiler that takes ASCII source files and creates object files in the native environment. Even in the line at a time mode, GT.M is actually generating object code under the covers. It does not come with a fancy environment, but it relies on the underlying tools available with the host OS. I have it reasonably well integrated with emacs (my favorite editor), and I wish I could find a mumps.el mode or that I had the time to write one. You can use CVS (or any other tool) for source code control. You can create a UI with Java, and hook it up to a GT.M database application. GT.M doesn't aim to be everything to everyone, but it has all the hooks needed to make what it does easily available to anyone that needs it. Oh, yes, there is just one datatype. It's a BLOB. What meaning to give to your BLOB is entirely yours. >>7. Why is M called a "database language?" M is a programming language with a strong emphasis on text handling and database management. However, M is NOT a data base management system. The disadvantage of being a programming language is that it takes more expertise to apply the language to create a working data base, but the advantage of not being a dedicated database management system is that it is infinitely more flexible.<< This would seem to make it very hard to use for my purpose (which needs access from C) [KSB] As noted, GT.M has a compiler for M that generates object code that calls a database runtime library. It is very much a database management system in that you can store data, retrieve it, share it, ensure ACIDity, continuous availability, etc. If you want SQL/ODBC access, schema documentation tools, reverse engineering tools, etc., they exist, but are not open source freeware. What's else is there in a database management system? I would like to hear from others on this forum. If this discussion is not of general interest, perhaps Emile and I should take this offline. *************************************************************************** This electronic mail transmission contains confidential and/or privileged information intended only for the person(s) named. Any use, distribution, copying or disclosure by another person is strictly prohibited. *************************************************************************** |
From: K.S. B. <k.b...@sa...> - 2000-11-19 13:13:29
|
To be complete, I should add that although GT.M is a heavy duty transaction processing database engine, one feature missing from GT.M is support for two phase commit. This is being considered for the future, but won't happen anytime soon (basically, we haven't yet figured out how to add it without a significant impact on performance). On the other hand, I don't know of anyone actually using two phase commit in production in a high performance transaction processing application based on the big name datanase engines -- on pretty much all of them (from what I hear), if you turn on two phase commit, everyting runs s-l-o-w-l-y. -- Bhaskar *************************************************************************** This electronic mail transmission contains confidential and/or privileged information intended only for the person(s) named. Any use, distribution, copying or disclosure by another person is strictly prohibited. *************************************************************************** |
From: Emiliano <em...@ir...> - 2000-11-19 14:49:51
|
K.S. Bhaskar wrote: > To be complete, I should add that although GT.M is a heavy duty transaction > processing database engine, one feature missing from GT.M is support for two > phase commit. This is being considered for the future, but won't happen > anytime soon (basically, we haven't yet figured out how to add it without a > significant impact on performance). I'm really a database newby. I don't know what a two-phased commit is. Does that mean you can have multiple changes withing one transaction? No, that can't be it. Please enlighten me. > On the other hand, I don't know of anyone actually using two phase commit in > production in a high performance transaction processing application based on > the big name datanase engines -- on pretty much all of them (from what I > hear), if you turn on two phase commit, everyting runs s-l-o-w-l-y. Hey, if banks can run their stuff without it, I highly doubt that I will need it. Thanks for taking so much time to answer this stuff. I realize I'm monopolizing the mailinglist a bit, sorry all. Emile |
From: K.S. B. <k.b...@sa...> - 2000-11-20 22:59:31
|
On Sunday, November 19, 2000 at 15:49:49 (GMT+0100), Emiliano wrote: > K.S. Bhaskar wrote: > > > To be complete, I should add that although GT.M is a heavy duty transaction > > processing database engine, one feature missing from GT.M is support for two > > phase commit. This is being considered for the future, but won't happen > > anytime soon (basically, we haven't yet figured out how to add it without a > > significant impact on performance). > > I'm really a database newby. I don't know what a two-phased commit is. > Does that mean you can have multiple changes withing one transaction? > No, that can't be it. Please enlighten me. GT.M has full ACID properties if it is the only transaction processing database engine. Two phase commit applies if there are multiple database back ends. Suppose there are two databases, say customer information kept in an LDAP server not written in GT.M (actually, GT.M would be a great database for an LDAP server, but that's another soapbox for another day) and banking information kept in PROFILE/Anyware, which runs on GT.M. Let's say you want to create a customer record, and a checking account as one transaction that must either be committed to all databases or not be committed to any database. The first part of a two phase commit is to verify that each database can commit the transaction and the second phase is to tell each database to commit it. -- Bhaskar |
From: Emiliano <em...@ir...> - 2000-11-20 23:20:14
|
"K.S. Bhaskar" wrote: > GT.M has full ACID properties if it is the only transaction processing > database engine. > > Two phase commit applies if there are multiple database back ends. > Suppose there are two databases, say customer information kept in an > LDAP server not written in GT.M (actually, GT.M would be a great > database for an LDAP server, but that's another soapbox for another > day) and banking information kept in PROFILE/Anyware, which runs on > GT.M. Let's say you want to create a customer record, and a checking > account as one transaction that must either be committed to all > databases or not be committed to any database. The first part of a two > phase commit is to verify that each database can commit the transaction > and the second phase is to tell each database to commit it. I see. I also see how this kind of stuff can get wickedly complex fast. OK, this is not something I need. It's funny you should mention that GT.M would make a good LDAP backend, since that issue too has crossed our projects discussions. The LDAP folks say that an RDBMS would be a very poor choice for a LDAP backend since it balances out read and write efficiency whereas an LDAP server needs blazingly fast reads, and slow writes are tolerable. How would GT.M stack up against this? I'm almost sorry I got involved. I can just see _tons_ of exciting possibilities for this storage engine, and I have so very limited time :/ Emile |
From: K.S. B. <k.b...@sa...> - 2000-11-20 23:36:51
|
On Tuesday, November 21, 2000 at 00:20:16 (GMT+0100), Emiliano wrote: <...snip...> > OK, this is not something I need. It's funny you should mention that > GT.M > would make a good LDAP backend, since that issue too has crossed our > projects > discussions. The LDAP folks say that an RDBMS would be a very poor > choice > for a LDAP backend since it balances out read and write efficiency > whereas > an LDAP server needs blazingly fast reads, and slow writes are > tolerable. > How would GT.M stack up against this? [KSB] GT.M has two access methods, one of which is to map the database to shared virtual memory (MM) , and the other is to use its own buffering and caching (BG). While both are currently supported on VMS, MM on UNIX is in prototype state. MM on UNIX may be well suited to blazingly fast reads and slow updates. Of course, GT.M may not stack up well against an LDAP server written from the ground up to be an LDAP server and nothing else. But the source code is very lightweight, which is what I think will make it run well. But why do you say that slow writes are tolerable for LDAP? Doesn't it depend on the application? > I'm almost sorry I got involved. I can just see _tons_ of exciting > possibilities for this storage engine, and I have so very limited time > :/ [KSB] Enough said about LDAP for now. As I said, I'll get on that soapbox another day. Back to work... |
From: Emiliano <em...@ir...> - 2000-11-20 23:46:53
|
"K.S. Bhaskar" wrote: > Of course, GT.M may not stack up well against an LDAP server written > from the ground up to be an LDAP server and nothing else. But the > source code is very lightweight, which is what I think will make it run > well. > > But why do you say that slow writes are tolerable for LDAP? Doesn't it > depend on the application? Not my words, but from talks with the OpenLDAP guys. I would agree that it depends on the application but it was said that the kind of stuff that LDAP excels at usually tolerates a scenario as above. Emile |
From: Jim S. <ja...@uc...> - 2000-11-20 20:57:01
|
Bhaskar wrote: > >-----Original Message----- >From: Emiliano >To: san...@li... >Sent: 11/18/00 2:24 PM >Subject: [Sanchez-gtm-core] Mumps comments > >Just some of the stuff I found while reading up on Mumps: > >>>M has many good points: high productivity, low hardware requirements, >>>good scalability. But M also has some weaknesses: low transaction >>>reliability, character-based screens, poor integration with other >>>environments, and few development tools. > > [Thomas C. Salander, M Computing, June 1994, p.74] Please note that Thomas' quote is over six years old. It is overly general and I am sure he would have qualified it extensively himself, if he were still alive. Virtually all of these concerns have been addressed in some way across M implementations, however I think that transaction processing - almost all current MUMPS implementations have addressed issues of reliability in the face of hardware failure, which I think is what this quote is referring to, not any outstanding question of reliability of database transactions in normal processing. - DTM, which is what I am most familiar with is highly reliable and recoverable based on distributed processing, journalling and and a live "shadow" backup system. - GT.M appears to go significantly beyond other MUMPS, including Cache', in its implementation of transaction processing commands introduced in the MUMPS 1995 Standard. character based screens - This is a characteristic of individual applications design, not anything intrinsic to MUMPS or virtually any other programming language. I have been working with an HTTP/HTML interface to our (VMTH VMACS) MUMPS applications for almost all of that time. I think the quote was a reflection of a general sense of frustration that MUMPS users had been experiencing back then in waiting for vendors to develop a GUI interface for M$Windows. That was one of the things that led us to develop a MUMPS web server. >M is a lousy language with one great data type. > > [Steve J. Morris]<< I think the comment is unfair to MUMPS, but I do agree that the best thing about MUMPS is the deceptively simple yet scalable concept of data as untyped ordered hierarchical associative arrays. I am not sure that Steve Morris ever really programmed in MUMPS, but he was associated with GUMP/FreeM for quite a while because he wanted to have access to MUMPS globals from C applications. BTW, exactly that appears to be available now with GT.M. >Do these still apply? > >[KSB] Don't believe everything you read, including my e-mails. 8-] > >The above may be true of the other MUMPsen, but not to GT.M. GT.M is the >database of record for many large banks. For example (since you may be from >Holland), you may well already have your bank balance in a GT.M database, >since ING is rolling Sanchez's PROFILE/Anyware application out worldwide! A >transaction processing engine that doesn't deal with full ACID properties is >not a transaction processing engine. Do we have bugs? Yes. Do Oracle, >DB2, and SQL Server have bugs? [The answer depends on whether you talk to >their engineers and users or their marketing and sales people.] > >GT.M does provide character based screens, just like other implementations. >The user interface for GT.M is entirely character based. However, we use >GT,M at Sanchez to run back end server processes for banking applications, >and those beautifully countoured buttons with textured shading are more >important at the front end on the user's PC. At Sanchez, the banking engine >is a server process (actually, many server processes, since GT.M scales up >very well in SMP environments, especially if you use transaction processing >features) that receive messages (e.g., transfer $100 from account x to >account y) via middleware from front ends which could be ATMs, browsers, >tellers, cellular phones, etc. They process these messages and reply via >messages. The back end is designed to be always on, and when logical dual >site is in use, to be always available, even if a terrorist blows up a data >center, or, more likely, when a major upgrade requires a database schema >change. > >Other MUMPSen may not integrate into the host OS environment. GT.M is a >compiler that takes ASCII source files and creates object files in the >native environment. Even in the line at a time mode, GT.M is actually >generating object code under the covers. It does not come with a fancy >environment, but it relies on the underlying tools available with the host >OS. I have it reasonably well integrated with emacs (my favorite editor), >and I wish I could find a mumps.el mode or that I had the time to write one. >You can use CVS (or any other tool) for source code control. You can create >a UI with Java, and hook it up to a GT.M database application. > >GT.M doesn't aim to be everything to everyone, but it has all the hooks >needed to make what it does easily available to anyone that needs it. > >Oh, yes, there is just one datatype. It's a BLOB. What meaning to give to >your BLOB is entirely yours. > >>>7. Why is M called a "database language?" > >M is a programming language with a strong emphasis on text >handling and database management. However, M is NOT a data base >management system. The disadvantage of being a programming language is >that >it takes more expertise to apply the language to create a working data >base, >but the advantage of not being a dedicated database management system >is that it is infinitely more flexible.<< > >This would seem to make it very hard to use for my purpose (which needs >access >from C) > >[KSB] As noted, GT.M has a compiler for M that generates object code that >calls a database runtime library. It is very much a database management >system in that you can store data, retrieve it, share it, ensure ACIDity, >continuous availability, etc. If you want SQL/ODBC access, schema >documentation tools, reverse engineering tools, etc., they exist, but are >not open source freeware. What's else is there in a database management >system? There are other tools as well, some already free such as Fileman from the VA. DBMS supporting any database model can be written (comparatively) easily in M since the hard part of providing flexible scalable persistent storage is already done. >I would like to hear from others on this forum. If this discussion is not >of general interest, perhaps Emile and I should take this offline. Please don't take it offline. If not appropriate here, perhaps comp.lang.mumps or GUMP or a new list if needed. --------------------------------------- Jim Self Manager and Chief Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) |
From: Emiliano <em...@ir...> - 2000-11-20 22:18:22
|
Jim Self wrote: > - GT.M appears to go significantly beyond other MUMPS, including Cache', in > its implementation of transaction processing commands introduced in the > MUMPS 1995 Standard. Interesting. Cache' is a Mumps implementation? That would certainly give backing to my choice of GT.M as a storage backend for our project. > character based screens > - This is a characteristic of individual applications design, not anything > intrinsic to MUMPS or virtually any other programming language. I have been > working with an HTTP/HTML interface to our (VMTH VMACS) MUMPS applications > for almost all of that time. I think the quote was a reflection of a general > sense of frustration that MUMPS users had been experiencing back then in > waiting for vendors to develop a GUI interface for M$Windows. That was one > of the things that led us to develop a MUMPS web server. The webserver itself is implemented in MUMPS, or an interface to an existing webserver? > I think the comment is unfair to MUMPS, but I do agree that the best thing > about MUMPS is the deceptively simple yet scalable concept of data as > untyped ordered hierarchical associative arrays. These hierarchies are strict then? No links/references? > I am not sure that Steve Morris ever really programmed in MUMPS, but he was > associated with GUMP/FreeM for quite a while because he wanted to have > access to MUMPS globals from C applications. BTW, exactly that appears to be > available now with GT.M. Yes, I'm reading up on DAL. > >[KSB] As noted, GT.M has a compiler for M that generates object code that > >calls a database runtime library. It is very much a database management > >system in that you can store data, retrieve it, share it, ensure ACIDity, > >continuous availability, etc. If you want SQL/ODBC access, schema > >documentation tools, reverse engineering tools, etc., they exist, but are > >not open source freeware. What's else is there in a database management > >system? > > There are other tools as well, some already free such as Fileman from the > VA. DBMS supporting any database model can be written (comparatively) easily > in M since the hard part of providing flexible scalable persistent storage > is already done. All the reading I've done so far (getting there, getting there) speaks of direct access to the data where you know the 'path' to your data on forehand. In order to implement something like SQL on top using only that, you'd have to traverse your entire dataspace to emulate a SELECT FROM WHERE query. Please tell me that's just a chapter away :) Not that I'd want to build an SQL database on Mumps (if I wanted that I'd stick with the RDBMS I use now) but it would make it understandable for me to see how one would go about it. > Please don't take it offline. If not appropriate here, perhaps > comp.lang.mumps or GUMP or a new list if needed. I subscribed to comp.lang.mumps so there'll be more people to bother. Is GUMP worth subscribing to given my current expertise level? Emile |
From: Emiliano <em...@ir...> - 2000-12-06 14:03:03
|
I'm ready to get my hands dirty with the DAL. Most things look not too hard, given the examples in the chapter. But I'd need some examples, or more info, on what things like gtm_order return. Also, gtm_init doesn't specify a database to connect to. How is the database used determined? And how is the actual connection made? TCP/IP, rpc, other? Also, how would I determine the max size of the data I can store in a node (for when I want to store chunked blobs)? Emile |
From: Thomas G. <to...@ad...> - 2000-11-19 14:42:19
|
On Sun, 19 Nov 2000, K.S. Bhaskar wrote: > The user interface for GT.M is entirely character based. However, we use The user interface to any industrial strength database is usually char mode...initially. With Postgres there is a psql interactive monitor along the lines of Oracle SQL*Plus/Sybase, etc. For me, with no exposure to mumps until recently, the FreeM/MumpsVM/GT.M/Cache prompt is reassuringly familiar. Due to its open source status - there have evolved over the 3 years I've used it, numerous interfaces to Postgres. So many that I couldn't list them all here. But the char mode and GUI options are many and varied. I am working with Ariel Brosch (author of the Language::Mumps module) to write a module for GT.M that collects data and spawns a mumps process. Being a basic perl guy (lazy and filled with hubris and greed) I've been whining relentlessly to Ariel (a good natured fellow) that there is no IF for GT.M along the lines of my beloved DBI::DBD. This is truly the best example of top shelf perl code and Ariel has agreed to look into writing a 'DBD' (database driver) for Mumps. I would love to see the idea applied to FreeM and MumpsVM as well. The approach of Tim Bunce's DBI (database interface) is to write a generic IF to SQL databases and then let others write specific 'Database Drivers'. This keeps the code (embedded SQL) fairly generic and allows portability. It also means that those familiar with ESQL/C will not feel lost the first time they write a script as the syntax is similar. I'd love to see a generic MDBI with specific MDBD drivers to allow connections to various flavours of Mumps while keeping the MDBI spare to allow for generic embedded M code. I am writing up a brief doc on my current approach. Since no DBI::DBD::GTm driver exists yet I have a perl-cgi script generates a mumps routine and then does a (play-action ;-) pass to a small c binary which fires up GT.M. This is a crude hack that works well and I will pass my doc onto Bhaskar this afternoon to do with what he will. Until folks like Ariel produce more sophisitcated modules my crude-but-effective approach has GT.M working with CGI in my shop - now. So my answer to the question of missing sophisticated interfaces is: GT.M has been in the public arena for less than a month and already skilled people are working on reversing the situation. > Oh, yes, there is just one datatype. It's a BLOB. What meaning to give to > your BLOB is entirely yours. The meaning I give is: large progress notes (psychiatrists are verbose by inclination and job description) can be easily stored and retrieved. That is what counts in my 'real' world situation. > This would seem to make it very hard to use for my purpose (which needs > access > from C) Emile, Jim Self was kind enough to pass this along to me: See chapter 12 - DAL (database access library). [ Thanks Jim ] > [KSB] As noted, GT.M has a compiler for M that generates object code that > calls a database runtime library. It is very much a database management > system in that you can store data, retrieve it, share it, ensure ACIDity, > continuous availability, etc. If you want SQL/ODBC access, schema > documentation tools, reverse engineering tools, etc., they exist, but are > not open source freeware. What's else is there in a database management > system? I am anxiously awaiting the <BR> OSS </BR> versions of these tools! (Emphasis added as OSS does *not* mean 'freeware', it means Open_Source. I say this because KSB - you refer to GT.M as 'open source freeware'. This is an oxymoron that will draw fire from GNU/Linux/FBSD purists. GT.M is GPL'd! This is outstanding - it is an open source product not some tepid middle-of-the-road 'freeware' with all sorts of dubious disclaimers and missing src. Lest you think I wax rhetorical, this is already an issue on the Postgres GENERAL mailing list where I had to mention to developers there that GT.M is indeed GPL.) > I would like to hear from others on this forum. If this discussion is not > of general interest, perhaps Emile and I should take this offline. These are real world issues. On some mailing lists where I lurk the focus is so totally theoretical that regular joes like me tune out. This discussion with Emile is REAL_WORLD and I suspect you will only have to answer these questions again (indeed ad nauseum) if you take it offline. Thanks for keeping your code and your discussion public! Cheers, Tom -------------------------------------------------------------------- SVCMC - Center for Behavioral Health -------------------------------------------------------------------- Thomas Good tomg@ { admin | q8 } .nrnet.org IS Coordinator / DBA Phone: 718-354-5528 Fax: 718-354-5056 -------------------------------------------------------------------- Powered by: PostgreSQL s l a c k w a r e FreeBSD: RDBMS |---------- linux The Power To Serve -------------------------------------------------------------------- |
From: Emiliano <em...@ir...> - 2000-11-19 15:05:53
|
Thomas Good wrote: > > The user interface for GT.M is entirely character based. However, we use > > The user interface to any industrial strength database is usually char > mode...initially. With Postgres there is a psql interactive monitor > along the lines of Oracle SQL*Plus/Sybase, etc. For me, with no > exposure to mumps until recently, the FreeM/MumpsVM/GT.M/Cache prompt > is reassuringly familiar. > > Due to its open source status - there have evolved over the 3 years I've > used it, numerous interfaces to Postgres. So many that I couldn't list > them all here. But the char mode and GUI options are many and varied. Understood. The texts I could find on Mumps so far stressed that you write M-only scripts/programs (I've seen both terms used) and I could find no references for GUIs or whatnot for M. But GUIs are not my main concern. Whatever database I choose will in the end be the storage backend for a multitude of services, accessed by FTP, filesystem emulation, HTTP, DAV, iCal, ... and for most of these I need non-interactive C-level and at some point Java access to the database. The texts I found didn't directly say that you couldn't, I now realize, but strongly stressed the M-only approach. > I am working with Ariel Brosch (author of the Language::Mumps module) > to write a module for GT.M that collects data and spawns a mumps process. > Being a basic perl guy (lazy and filled with hubris and greed) I've > been whining relentlessly to Ariel (a good natured fellow) that there > is no IF for GT.M along the lines of my beloved DBI::DBD. This is truly > the best example of top shelf perl code and Ariel has agreed to look > into writing a 'DBD' (database driver) for Mumps. I would love to see > the idea applied to FreeM and MumpsVM as well. Perl access! Yes! Want! > > Oh, yes, there is just one datatype. It's a BLOB. What meaning to give to > > your BLOB is entirely yours. > > The meaning I give is: large progress notes (psychiatrists are verbose > by inclination and job description) can be easily stored and retrieved. > That is what counts in my 'real' world situation. Good. If you can do this I suspect my needs can be served. > > This would seem to make it very hard to use for my purpose (which needs > > access > > from C) > > Emile, Jim Self was kind enough to pass this along to me: > See chapter 12 - DAL (database access library). [ Thanks Jim ] Will do. I hadn't gotten to that point and I just have all these questions... > I am anxiously awaiting the <BR> OSS </BR> versions of these tools! > (Emphasis added as OSS does *not* mean 'freeware', it means Open_Source. > I say this because KSB - you refer to GT.M as 'open source freeware'. > This is an oxymoron that will draw fire from GNU/Linux/FBSD purists. > GT.M is GPL'd! This is outstanding - it is an open source product > not some tepid middle-of-the-road 'freeware' with all sorts of dubious > disclaimers and missing src. Lest you think I wax rhetorical, this is > already an issue on the Postgres GENERAL mailing list where I had to > mention to developers there that GT.M is indeed GPL.) Agreed here. I'm working on an Open Source project and having the main component (and the storage system would in fact be the defining component) be GPL is a must-have. Which brings me to another question: will all parts of GT.M be GPL? Or will things like the database access library be LGPL? Emile |
From: K.S. B. <k.b...@sa...> - 2000-11-20 23:24:49
|
On Sunday, November 19, 2000 at 16:05:51 (GMT+0100), Emiliano wrote: <...snip...> > Agreed here. I'm working on an Open Source project and having the main > component (and the storage system would in fact be the defining > component) be GPL is a must-have. Which brings me to another question: > will all parts of GT.M be GPL? Or will things like the database access > library be LGPL? [KSB] I lean to GPL. However, someone has recently made a plausible case to consider the Mozilla Public License, and I have promised myself that I will at least go back and re-read GPL and MPL carefully. -- Bhaskar |
From: Emiliano <em...@ir...> - 2000-11-20 23:44:51
|
"K.S. Bhaskar" wrote: > > On Sunday, November 19, 2000 at 16:05:51 (GMT+0100), Emiliano wrote: > > <...snip...> > > > Agreed here. I'm working on an Open Source project and having the main > > component (and the storage system would in fact be the defining > > component) be GPL is a must-have. Which brings me to another question: > > will all parts of GT.M be GPL? Or will things like the database access > > library be LGPL? > > [KSB] I lean to GPL. However, someone has recently made a plausible > case to consider the Mozilla Public License, and I have promised myself > that I will at least go back and re-read GPL and MPL carefully. I can't say I'm up to speed on the MPL. We're GPL ourselves, so GT.M being GPL would not pose a problem for us. Just curious. Emile |
From: Emiliano <em...@ir...> - 2000-11-19 14:55:02
|
K.S. Bhaskar wrote: > [KSB] Don't believe everything you read, including my e-mails. 8-] > > The above may be true of the other MUMPsen, but not to GT.M. GT.M is the > database of record for many large banks. For example (since you may be from > Holland), you may well already have your bank balance in a GT.M database, > since ING is rolling Sanchez's PROFILE/Anyware application out worldwide! A > transaction processing engine that doesn't deal with full ACID properties is > not a transaction processing engine. Do we have bugs? Yes. Do Oracle, > DB2, and SQL Server have bugs? [The answer depends on whether you talk to > their engineers and users or their marketing and sales people.] *grin* I had an account at ING a while. I have no complaints about their technical service. Their customer service, however... :) Anyway, OK, this does put things in perspective for me. > You can use CVS (or any other tool) for source code control. You can create > a UI with Java, and hook it up to a GT.M database application. How do these external interfaces interact with GT.M? The socket interface? > Oh, yes, there is just one datatype. It's a BLOB. What meaning to give to > your BLOB is entirely yours. Just what I've been looking for. *pinks away a soletary tear* And just in time, too. We've been searching high and low for a tool like this, having found that relational is simply a bad match for our needs. We were about to embark on writing our own database. > I would like to hear from others on this forum. If this discussion is not > of general interest, perhaps Emile and I should take this offline. *looks around* Yeah, sorry guys. Let me know. Emile |
From: K.S. B. <k.b...@sa...> - 2000-11-20 23:10:38
|
On Sunday, November 19, 2000 at 15:55:00 (GMT+0100), Emiliano wrote: <...snip...> > > You can use CVS (or any other tool) for source code control. You can create > > a UI with Java, and hook it up to a GT.M database application. > > How do these external interfaces interact with GT.M? The socket > interface? [KSB] GT.M source & object code files are just ASCII files in the file system of the native OS. Therefore, you can use your favorite flavor of emacs to edit source code, CVS for version control, etc. Other MUMPSen store the programs in the database. You would use the socket interface to connect Java to the database, or take the database runtime library and link it with the JVM to create a tight binding. The latter is something we are considering doing. > > Oh, yes, there is just one datatype. It's a BLOB. What meaning to give to > > your BLOB is entirely yours. > > Just what I've been looking for. *pinks away a soletary tear* And just > in time, too. We've been searching high and low for a tool like this, > having found that relational is simply a bad match for our needs. We > were about to embark on writing our own database. [KSB] There are many databases available, many in source code too, and many that can handle non-relational data. While writing a database engine can be very enjoyable (now that I am a manager, I can reflect on how therapeutic it was when I wrote code), and is actually very easy to do, it is hard to write a database from scratch that has a lot of robustness out of the box. The code that actually runs repeatedly in GT.M is a small part of the total code base. Much of the code is intended to ensure that big things don't go wrong when little things go wrong. Systems for the real world need to be able to operate robustly or shut down gracefully even in the presence of failure. Cases when one thing goes wrong and causes catastrophic events -- like a metal strip on a runway when a Concorde is taking off -- are rare events in a well engineered system. |
From: Emiliano <em...@ir...> - 2000-11-20 23:43:41
|
"K.S. Bhaskar" wrote: > You would use the socket interface to connect Java to the database, or > take the database runtime library and link it with the JVM to create a > tight binding. The latter is something we are considering doing. OK, so I could use the socket interface to talk M to the database from my C program until I have the DRL to talk to the database directly. > [KSB] There are many databases available, many in source code too, and > many that can handle non-relational data. I've found some, but they were generally proprietary, research-only (as in "it works, let's go do something else") or simply extremely alpha. Often more than one of these applied. I'd be most interested in any references you have for something that doesn't match the above traits. > While writing a database > engine can be very enjoyable (now that I am a manager, I can reflect on > how therapeutic it was when I wrote code), and is actually very easy to > do, it is hard to write a database from scratch that has a lot of > robustness out of the box. I know how that feels :) But our project is about creating a content management system, and our strength lies not in creating things from scratch but glueing stuff together. If we have to we'll build our own database but I'd simply prefer to use someone elses' experience whenever possible. Emile |