Few words about Vserver 2.4 - point 1

[Ruslan Zasukhin]

Hi All,

I want describe a little what happens in background.

* as I have told we have automate process of sources generation.
    
    Now each function that we have in public C++ interface
    is auto-generated in Vclient and Vserver sources.

    On default vclient STUB object send remote call to vserver PROXY object.

    This idea have allow us to get VCLIENT which work absolutely the same
    way as KERNEL do.

    Problem with 2.3 Vclient was that on client side was repeated a lots of
    logic of kernel, and often was mistakes...just because kernel is big,
    logic is complex, clients have data members to keep state,
    this did require synchronize state to server objects...

    I.e. We did have in fact 2 branches of code which did try
    to do similar things.

    Now, again, Vclient, on first level, - just delegate function call to
    Server objects.

    
* But it is obvious that if for SQL way this is quite acceptable way,
for API way this cause big network overhead. So second level of VCLIENT and
VSERVER try optimize and compensate first level.

How we do this.

We again plug into VCLient some logic, but only fundamental logic which
unlikely will be ever changed.

For example, vclient object VTAble on second level know its fields, links,
and database. I.e. Vclient objects know hierarchy of objects.

This fact have allow us avoid send to server requests for such methods as
    Vtable.Field(i)

On the other hand this again bring PROBLEM - how to synchronize client
objects to server objects, for example in case some user A have issue DROP
FIELD, how propagate this change to all other clients that work with the
same table. 

For now we have workaround -- db.get_Table() method always force load from
server full structure description of a table.

Important is that we already see way how to solve this in much better and
transparent for user way. We plan to implement this solution for 2.5
release. I will describe this solution in next letter.


P.S. About issue of slow API method Vtable.AddRecord() that Russ have found.
I have to see that after AddRecord() in server log present set of
Vfield.get_DefaultValue. The more fields in table the more such commands. We
need simply override this method on second level to avoid request to server.
Sorry, we have overlook this moment. We will try fix it in nearest time.


-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]