Subject | Re: [Firebird-Architect] Re: Clumplets and formats. |
---|---|
Author | Alex Peshkov |
Post date | 2008-01-15T08:32:10Z |
On Saturday 29 December 2007 18:11, dmitry.lipetsk wrote:
clumplet instead of using messages like it's done now? What properties do you
mean here?
revolution.
> Hi AlexCan you be more specific here? Do you suggest to transfer parameters in
>
> > 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?
clumplet instead of using messages like it's done now? What properties do you
mean here?
> ----Should we pass sql and blr in clumplets too? I was not going to prepare SUCH
> I think that we must pass
> - ID (guid) of tags group
> - TypeID (sql/blr/other) of tag value
revolution.
> Also, we must has decision for transfer two and more buffers as one.What is EE? And once again no idea - what do
> 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 :-)