From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ac39a12d5faf5b14 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-26 10:16:47 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!ra.nrl.navy.mil!dca6-feed2.news.algx.net!allegiance!newsfeed1.cidera.com!Cidera!cyclone.columbus.rr.com!cyclone3.kc.rr.com!news3.kc.rr.com!twister.socal.rr.com.POSTED!not-for-mail Message-ID: <3CC98B8E.D49A2CEE@san.rr.com> From: Darren New X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Grace and Maps (was Re: Development process in the Ada community) References: <3CB46975.90408@snafu.de> <3CBAFFEE.2080708@snafu.de> <4519e058.0204171036.6f0a7394@posting.google.com> <3CBDD795.4060706@snafu.de> <4519e058.0204180800.44fac012@posting.google.com> <3CBF0341.8020406@mail.com> <4519e058.0204190529.559a47ae@posting.google.com> <3CC1C6B3.6060306@telepath.com> <3CC21747.5000501@telepath.com> <3CC59ED2.1000803@home.com> <3CC5B286.6FE61551@san.rr.com> <3CC5B9EE.32F3060@san.rr.com> <3CC83282.69C1884F@san.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 26 Apr 2002 17:16:21 GMT NNTP-Posting-Host: 66.75.151.160 X-Complaints-To: abuse@rr.com X-Trace: twister.socal.rr.com 1019841381 66.75.151.160 (Fri, 26 Apr 2002 10:16:21 PDT) NNTP-Posting-Date: Fri, 26 Apr 2002 10:16:21 PDT Organization: RoadRunner - West Xref: archiver1.google.com comp.lang.ada:23145 Date: 2002-04-26T17:16:21+00:00 List-Id: Marin David Condic wrote: > In the olden days, disk based maps were called "ISAM Files" :-) Actually, I think that was IBM nomenclature for an access mode. I've seen "KSAM" as well (Keyed Sequential Access Method) to get around the trademarks. But yes, ISAM was that API to disk-based maps, with b-trees or whatever being the implementation. > 1) As long as we have some kind of stream based mechanism to be able to > load/store a map or list to a file, this ought to account for *most* uses of > the data structures since it has to get pretty big to start causing problems > in today's world of cheap & virtual memory. Hrm. Maybe, maybe. Depends on what kind of program you're writing. I'd hate to suck up and blow out a 10-meg stream file for every hit on my CGI site where I want to look up one record out of 100,000. Now, what *would* be cool is if the read-stream routines for the ISAM implementation could understand the write-stream results from the in-memory set. Then moving from your suggestion to a "real" disk-based database is a matter of sucking it in once, then stuffing it into the disk-based map. > 2) If you want some version of an ISAM file, that's fine, but it *is* a file > so it will likely have needs beyond what an in-memory structure would > require. At that point, I'd say you'd want to at least have a high level of > similarity between the interfaces, but I wouldn't feel the need to have a > slavish compatibility between the two. We should put it in our back pocket > for another day and just be sure that whatever spec is built for Maps, that > it is sufficiently abstract to hide the particulars of the implementation. > That really ought to be enough. I think that was my suggestion. Obviously, you'd need stuff like a file name, a utility to perhaps pack the file down to minimum size, etc. But my intent in saying they had the same spec was to imply that in actuall *access* routines, there needn't be arbitrary changes to the API. Open and close, sure. But not iterating thru the records, adding or deleting, etc. > We've got to be *real* careful not to make a naming scheme that tries to > have so many branches to such a depth that everyone will later decide that > it is a Royal Pain In The Posterior to use it. Yah. Welcome to Java, where you need to instantiate half a dozen abstract mail APIs just to send an email message that's a printf in C. :-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%.