[Info-vax] Long uptime cut short by Hurricane Sandy

[Chris Scheers]

Stephen Hoffman wrote:
> On 2013-02-06 01:00:46 +0000, AEF said:
> 
>> On Feb 5, 10:48 am, Stephen Hoffman <seaoh... at hoffmanlabs.invalid>
>> wrote:
>>> So you are seeking a key-value data store, something that logical names
>>> classically excel at stinking at.
>>
>> I'm not familiar with the term key-value data store.
> 
> In RMS terms, think "indexed file".  You have a Key.  And you have a 
> Value associated with it.
> 
>> And I take it
>> you're saying that for this purpose, logical names stink well.
> 
> Ayup, logical names commonly used for this, and I've used them for this 
> myself, and I've learned to completely despise this approach.
> 
> Logical names are a disaster for this usage; for storing information and 
> for storing and retrieving preferences data, or application data.
> 
>>
>>> Logical names got us the morass that is the DEC C feature logical
>>> names, after all.
>>>
>>> Sure, it works.
>>>
>>> At least until you trip into some other user; a collision.
>>>
>>> Or you need to scan all keys, as both VMS and environment variables
>>> lack wildcards.
>>
>> In TO.COM you can set it so that all its logical names start with
>> TO_ . This should avoid a collision. Instead of TO_0, TO_1, TO_2,
>> etc., I prefer HERE, LAST, 2BACK, 3BACK, . . . . They're much easier
>> and faster to type, and that has never cause me a problem. If it does
>> cause a problem you can instead use the TO_ versions. So where's the
>> problem?
> 
> The problem is you have a crap-ton of random logical names, with no 
> connections, with the possibility collisions, with no clean-up 
> mechanisms, and usually then with the general disaster that the DECC$ 
> mechanisms have garnered themselves.
> 
> Both the stuff I mentioned above, and the stuff I mentioned below:
> 
>>> Upgrades can be fun, where these are added or removed; there's no
>>> "attachment" back to the application.
>>>
>>> No namespaces, for that matter.
>>>
>>> There are other issues.
> 
> Logical names get abused far too often, largely because DCL lacks any 
> sort of a generic preferences storage and retrieval mechanism, or an 
> integrated key-value mechanism short of using (for instance) an RMS 
> indexed file.
> 
> This design inevitiably reminds me of using punch cards to store this 
> data.  Sure, that works.  It's even superior to using logical names in a 
> way.  But it's really ugly, it's a whole lot of work for what you get, 
> and it's quite easy to make mistakes, and upgrades and cleanups can be a 
> problem.  Unlike a deck of punch cards, logical names don't have a way 
> to read the whole wad of keys and values — data — and see what's there, 
> too.

Logical names DO have name spaces.  (They just aren't used very often.)

What is wrong with using application specific logical name tables?

Of course, you need to make sure you don't have collisions in table 
names, but some level of organization is required for any solution.

-- 
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360            Internet: chris at applied-synergy.com
   Fax: 817-237-3074