Kevin
On 1/14/06, LD 'Gus' Landis <[EMAIL PROTECTED]> wrote:
Hi,
Sounds like an opportunity for an SSVN to me.
What is the "vox populi" on the notion of SSVNs anyway?
Cheers,
--ldl
On 1/14/06, Jim Self <[EMAIL PROTECTED]> wrote:
> Bhaskar wrote:
> >Code specific to each MUMPS implementation should belong in the kernel,
> >isolated from the applications.
> >
> >GT.M doesn't provide a function to stat a file. The two approaches
> >would be to use ZSYstem to call a program like ls, stat or file, or to
> >call a standard C library function to get the answer.
>
> This reminds me of what I think might be THE most elegant way to extend MUMPS to a more
> complete computing paradigm. Allow direct mapping of a global to a directory of files such
> that from the MUMPS side, a file could be treated simply as a global variable, and from
> the OS side, MUMPS data (some, not necessarily all) could be made directly accessible to
> other applications.
>
> When I was (prior to GT.M/Linux) actively seeking a way forward for MUMPS development that
> could avoid lock-in to proprietary databases and trying to find a way to have the benefits
> of MUMPS globals in other programming languages, it occurred to me that the closest thing
> to MUMPS globals outside of MUMPS is the file system provided by each OS.
>
> Both provide an ordered hierarchical collection of persistent shared named values. MUMPS
> globals are generally optimized more for speed of access to a larger tree of data with
> generally smaller data values, but the similarities seem amazingly close to me.
>
> The primary differences are that
> 1) files are essentially unlimited in size where MUMPS data values
> generally have been constrained to a size of hundreds or perhaps
> thousands of bytes. GT.M now allows local values up to one megabyte
> but limits global values to blocks of 1KB up to 32KB (last I checked).
> 2) Every file generally has individual access permissions but an individual
> global reference generally does not. Some MUMPS implementations allow
> individual globals to map to separate files while others allow ranges of
> subscripts within a given global to be mapped to different files.
>
> Providing an optional globals model that simply maps a global to a directory of a file
> system would make the exchange of data with other applications simpler and more uniform, A
> MUMPS data file that could be mounted as a file system for some purposes could provide a
> potentially faster file system.
>
> ---------------------------------------
> Jim Self
> Systems Architect, Lead Developer
> VMTH Computer Services, UC Davis
> ( http://www.vmth.ucdavis.edu/us/jaself)
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Hardhats-members mailing list
> Hardhats-members@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hardhats-members
>
--
LD Landis - N0YRQ - from the St Paul side of Minneapolis
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
