Valentina 2.0. -- What is your 3 DREAM features?

[Robert Brenstein]

>  > -- be able to query ANY parameters/options that are settable by us or
>>  by kernel, including things like file mode, file block size, mac file
>>  type/create, file extensions.
>
>You mean by SQL?
>No promise. WE have start add SQL command SET PROPERTY, GET PROPERTY,
>But on the hold now.

Direct API will do. Actually non-SQL way is better for now. Those 
things are needed only under special circumstances.

>  > -- be able to store single global/persistent values easily (using
>>  system tables instead of having to maintain my own bo)
>
>Close to SET PROPERTY.

Property of what? I must have missed this topic somehow. But if they 
allow me to maintain single global values, I am game. But make them 
available in direct API as well.

>  > -- add SQLSelectField and SQLSelectGlobal
>
>?

Search list archive for this thread.

>  > -- option to have automatic time stamping of all or specific fields
>>  in a baseobject (updated only when content changes)
>
>Yes, we have add DB.Clocks(), and TIMESTAMP field.

Is the TIMESTAMP an internal field (handled automatically by kernel) 
or it is a field for us to use explicitely? Ideally, a field would 
have a property "timestamp" settable through Field_SetFlag() and then 
we have a call Field_GetTimestamp() to find the current value. It 
should also be properly handled through SQL, so we can easily find 
records with fields that were modified after specific timestamp.

>  > -- does valentina automatically zeros out space that becomes empty
>>  when existing data is encrypted? if not it should. And add an option
>>  for doing this upon any record deletion (a new call or an option for
>>  delete/all/Record/s)
>
>Yes, is added new flag db.EraseOnDelete.
>For non encrypted also

For non-encrypted should be optional for performance reasons.

>  > -- built in options to compress large data upon storage and auto
>>  decompress upon recall (choice of compression)
>
>Mmm, this exists now -- ZIP compression for BLOBs.

Hmm, may be it exists but there is no mention of it in any of the 
docs I have, so I have no clue how to use it.

I'd like this to be simply a field attribute like with indexing or 
unique -- I just call Field_SetFlag() to make field zip-compressed.

By BLOBs, do you mean BLOB fields or all BLOB-type fields (that is 
BLOB, TEXT, PICT)?

>  > -- simplify opening/creating encrypted database: New +
>>  Set(Structure)Encryption + Open --> CreateEncrypted and
>>  Set(Structure)Encryption + Open --> OpenEncrypted with Open returning
>>  an error dbEncrypted when trying to open an encrypted db. Also
>>  IsStructureEncrypted(fpath), IsDatabaseEncrypted(fpath) to check what
>>  kind of db we have (this was discussed on the list last year)
>
>Let's discuss this in separate thread.
>And I did agree in the past with changes?
>Just not sure it is possible simplify something.

Search list archive for past discussions. No, you did not actually 
agree to do this. But yes, I still find these steps non-intuitive and 
more complicated than needed, particularly for programs that allow 
our users to have either encrypted or unencrypted databases. Now it 
is an opportunity to clean this up.

Your current approach may be logical in VSDK but not in higher 
languages. I don't care what you do internally -- you can just call 
the current functions as they are.

>  > -- implement auto timeout of cursors
>
>What you mean?

See page 18 of vxcmd manual from December. Although to be truly 
useful, this should be a property of a cursor not a database (a 
parameter on SQL call that sets max age in seconds, 0 meaning no 
expire).

>  > -- option to open databases in read-only mode (as parameter to open
>>  or separate call) regardless whether it is on read-only or read-write
>>  medium
>
>Aha, as flag on open....
>I afraid not works.
>
>Assume files are not marked.
>One app open as read only. Ok.
>But other open as read/write => BIG PROBLEMS.

I am not sure problems are so big (at least in my ignorance :)

So what if the other app modifies a content of the field. The first 
app will get the new content (ya, live cursor modifiable by others). 
That is often desirable. If the 2nd app deletes a record, first 
should get an error "recordDeleted". If 2nd app makes any structure 
changes, 1st app returns "cursorNoLongerValid" error. Do I miss 
anything?

But, you can (at least initially) restrict that if a db is open for 
read, other apps can open it also for read only. A lock file could be 
used if there is no better way. (A change file could be used to pass 
level of changes from the read/write up.)

>
>>  -- valentinaInit returns the size of actually allocated cache
>
>Right now.

Hmm. In vxcmd, it returns empty when successful.

>
>  > -- use opportunity to clean up function/param names in BO-APIs
>
>?

For example, SetStructureEncryption()/SetEncryption() should be 
really called PassStructureEncryptionKey()/PassEncryptionKey() since 
that is what they do. But (cf above) encryption key should be passed 
with OpenEncrypted() not as a separate call aynway.

A few other examples:

Database_Dump() could be Database_WriteDump() or Database_MakeDump() 
to parallel Database_LoadDump(). May be even better to make them 
Database_ExportDump() and Database_ImportDump() to parallel 
Database_ExportAscii() and Database_ImportAscii(). Anything you write 
out to an external file is export and anything you read from external 
file is import.

Cursor_GetField() could be Cursor_GetFieldValue() to match 
Cursor_GetFieldName(), Cursor_GetFieldRef() and also Field_GetValue() 
-- or the latter should be Field_Get to match Cursor_GetField. 
Actually, Cursor_GetFieldContent() and Field_GetContent() would be 
even more appropriate.

Cursor_SetBlank() does not set the whole cursor so it should be 
Cursor_BlankRecord() or Cursor_SetRecordBlank().

I realize that we got used to those names as they are but changing to 
version 2 is a unique opportunity to make function names more 
self-descriptive with less ambiguities. I just like them nice and 
clean and logical :)

A new item:

Do you remember THINK Reference? It was basically a smart searchable 
database that contained syntax of all functions from System Toolbox 
and Think language reference. May be such a database convering all 
your products would be useful for us and you. There would be a 
standalone GUI to use it but the raw database would be also available 
for integration into at least some development environments.

Robert