> 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?

Can you be more specific here? Do you suggest to transfer parameters in
clumplet instead of using messages like it's done now? What properties do you
mean here?

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

Should we pass sql and blr in clumplets too? I was not going to prepare SUCH
revolution.

> 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)

What is EE? And once again no idea - what do
******** Sorry - pressed SEND accidentially... ***************
you mean under properties here? Why send something in separate buffers?

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

This contradicts with whole DPB idea - client sends what it needs, server (old
one) can skip what it does not know.

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

Do not like it. Typically clumplets are small, but some may be very big. I
know networks are fast now, but sending 4Gb for every clumplet is a bit
overhead:-)

> 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 good (except unnamed parameters) for literal strings, but I'm not sure
how good will it work for encrypted using public key password.
And next - it's very good when you write program using API with fixed password
and username, but I'm not sure this is much better compared with current
approach when you must prepare DPB in, for example, ODBC provider.