Hi Alex

> I suggest to replace all this varieties with single common format

(it may

> be
> tagged or not tagged).

Your suggestions is good

But really - this is replacing "awl to soap"

Yes, we get a virtual size of length field

We can use this technology for tagID field also.

All this good for transfering these datas across network boundaries

You think, this is enough for new clumplets (params, properties ...)
representation?

----
I think that we must pass
- ID (guid) of tags group
- TypeID (sql/blr/other) of tag value

Also, we must has decision for transfer two and more buffers as one.
For
instance
- the first buffer with standard properties
- the second buffer with unique properties for some EE (like the
Vulcan -
bu-ga-ga)

The first buffer and the second buffer can have a tags with equal
IDs. But
this tags live at separated groups with different IDs.

----
We must have the way for getting list of support tags.

----
What you think about clumplet with the fixed size? We can present
value in
VARIANT-like structure...

----
Also. In some cases we can define and transfer properties through
single
string like "param1=value;param2=value2..."

isc_attach_database(...,"database_path;user
id=sysdba;password=masterkey")

"database_path" - in this case, the unnamed parameter

---
This is only my thoughts.

Kovalenko Dmitry

PS. See the structures and interfaces for work with properties in
other
DB-technologies. You can find the many interesting things :)

PSS. We can discuss these things, but, am afraid, I not have time for
it

PSSS. Happy New Year :-)