Posted by Jon Sacks on October 24, 2004 at 06:18:53:
In Reply to: Informal NYC Dealer Meeting posted by Jim Guerber on October 23, 2004 at 19:56:18:
• Want support for long filenames - Requires eliminating qdirs. For sequential and contiguous files we could create a secondary file with same name and an extension that would hold the necessary file attributes. 3-character Comet dir name would have to be stored in a file also. Also need to supply utility for old keyed files that would copy file attributes into TKS.
**You have this in the cfg, you don't need to track directory name.
• Want Comet Explorer Maintenance Utility to support text files rather than launch text editor.
**Want CE to launch the application associated by the user. Same as Windows Explorer/Tools/File Types/Associations.
• Revamp NOVA and SNOVA. Want more modern Windows look for help messages and lookup programs.
**Agree, It would be good to specify lists, pull downs and radio button type lists.
• Comet University: want to revive training classes.
**Would love to see a class called "Updating to 2005" with sub sessions on each element.
• Nobody seemed at all interested in the proposed Comet security enhancements.
**Could not disagree more, security should be a concern for all developers and they should be educating their users on the value. The idea to create file level security provided by the server for users and user groups is a powerful tool. Integration with MS Active Directory should be done. It is imperative for larger installations.
Users and files should be objects. All objects should have an array of groups. For instance:
A bookeeper may belong to a group ACCOUNTING with rights of READ, WRITE, MODIFY, DELETE.
A Customer Service Manager may belong to CUSTOMER_SERVICE with rights of READ, WRITE, MODIFY, DELETE.
The PAYABLES file may have the group ACCOUNTING associated with it. An attempt by the Customer Service Manager to open the file would return an IB EXCP "Invalid Security".
The security would need to be a global setting at the server level to allow for legacy users that do not want to install it.
• Search for MTB programmers
**Would like to see a database that shows special skill sets, i.e. XAP, CFAM, DBMgr and certification program by signature. Would like to see "Gold" certified developers.
• Multiple key file system – on secondary keys, use “Key
Contains” as well as “Key =” – jim will write syntax spec
**Multiple keys should be transparant to the IB developer, the system should maintain a table of the keys for a specified file that is read from the key header on the open by the file system and stored.
The table would indicate:
Field Type Offset Length
------------------------------------------
CUSTOMER_NUMBER Primary 0 6
CUSTOMER_NAME Secondary 7 30
CUSTOMER_ZIP Secondary 55 10
CUSTOMER_STATE Secondary 90 2
The secondary keys would be written to the key portion of the file with Key Type + Field Name + Key Value + Primary Key + Data File Position/Offset.
Any write to C1A would write the secondary keys.
IB would need to be enhanced with a new verb for each key access statement called "KeyIndex" that would specify the key the system is to use to retrieve the record.
READ (C1A,C1AFullFormat),KEY="01025" KeyIndex="CUSTOMER_ZIP"
POSITION (C1A) KeyIndex="CUSTOMER_ZIP"
Reads without a "KeyIndex" would read only records specified with the primary key. This would allow legacy programs to remain unchanged.
A new EXCP value would also be required to indicate "End of KeyIndex Range".
I am on the fence if the secondary keys should be in a new file I01. I think this needs more discussion. My vote is to maintain the keys in the current I00 file.
Another powerful tool this could open up is the idea of triggers. If the file system were set up to spawn a procedure based on a KEY file modification, not only could secondary keys be written but secondary files could be updated.
This would require the ability to have the File system execute pre defined procedures associated with the field.