Hi David and all,

In the documentation (pool.pd and elsewhere) you talk about "directories" and such. But when I send a "mkdir" message, a directory is NOT created on my hard drive. I'm assuming then that I'm misunderstanding the nomenclature. I've never used the [coll] object in Max.

All the operations on the pool object are in-memory. "Directories" provide just a way to organize data in a hierarchical manner.

Here's the question: Pool is really managing "arrays" or "dictionary" objects right? I mean KEY

• VALUE pairs in the Visual Basic world are referred to as

dictionaries. Arrays are values organized by 'index' (or in this simile: 'keys' which can be named).

"Dictionary" would be appropriate, yes. In the moment a usage for indexed "arrays" is not efficient... pool is in its early stage and all searches are done linearly. In the future i plan to use some efficient algorithms that can handle sparse data equally well.

So in another sense, Pool and it's ability to 'mkdir' etc. is simulating the creation of database tables right? Or perhaps another analogy might be "recordsets"? I'm grasping a little here, but even in this early version of [pool] I can already understand ways that I can simulate columns and rows of records and even store information in different 'directories' as you say (which seem a lot to me like 'tables').

Hmmm , i'm not good at database stuff, but i guess that's true, although rows and columns is no good analogy. Matrix (or n-dimensional rectangular) data is not (yet?) handled well.

I understand that all the data is held in memory until such time as I want to commit the data to a file on my drive via the "save" method. When I do this, it's sort of like saving the database tables in a .dat file right?

Yes.... hopefully one of the next versions will bring XML support

I realize that [pool] is merely in its first version (and is already awesome!) but I wonder if there are plans in the future to: a) allow the values to be returned by index (a la Visual Basic dictionaries) in cases where we might not know the KEY name...but we now it's index. b) allow control of a cursor (a la recordsets) so that operations like "movenext" or "movefirst" might be used?

Yes, that will definitely be included. I have yet to see how that can be done efficiently since there is no internal indexing in pool.

p.s.: I know I know I know...give me an inch and want a mile right!? I suppose I'm just really excited about this object. It's already useful in a million ways.

Well, that's just ok! One always needs a bit of stimulation...

best greetings, Thomas