Path: utzoo!attcan!uunet!decwrl!wuarchive!udel!ee.udel.edu From: new@ee.udel.edu (Darren New) Newsgroups: comp.sys.amiga.tech Subject: Re: Files larger than available memory. Message-ID: <32894@nigel.ee.udel.edu> Date: 9 Oct 90 17:00:32 GMT References: <1990Oct7.032409.22928@zorch.SF-Bay.ORG> <1990Oct9.061755.15112@zorch.SF-Bay.ORG> Sender: usenet@ee.udel.edu Organization: University of Delaware Lines: 24 Nntp-Posting-Host: estelle.ee.udel.edu In article <1990Oct9.061755.15112@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >As a checklist for what this facility should provide, an editor is a >pretty good worst case, particularly one, like emacs, Yeah, I'd say EMacs is a worst-case. :-) :-) :-) Seriously tho, you also want to consider an object-oriented memory, possibly supporting a database system of some sort. You would like it to be persistant, quick to access, and maybe even garbage collectable. The primitives that you think up when thinking about editing buffers are *very different* than the primitives you think up when you consider keyed access (like btrees), variable-size records, quick random access, persistance, pointers to other pieces of memory, and so on. If you want a library only for editors, why not just write the editor to do its own paging? It would be much easier and more efficient than setting up a general system. If you want ideas on other things that people (or person :-) would use the library for, I'd be glad to explain how I use mine. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee -----