[ALL] let's think about Query Language for 2.0

[Andreas Grosam]

On Freitag, Mai 23, 2003, at 09:43  Uhr, Ruslan Zasukhin wrote:

> on 5/23/03 10:07 PM, Andreas Grosam at agrosam at computerworks.ch wrote:
>
>>>> One thing, not explicitly mentioned, if I understand you right, this
>>>> API shall work in a client/server environment as well??
>>>
>>> May be not. May be yes.
>>>
>>> Do not forget, I always try keep Valentina as flexible as possible.
>>> It should work fine as embedded engine, and as client server.
>>> As single user so multi-user
>>> As RDBMS, so object - relational.
>>
>> I though that, thus I emphasised the question  ;)
>>
>> I have an idea how to solve that  - it's basically, a design question:
>> Using template POLICIES for the objects realising the communication
>> between server and client.
>
>> For an embedded DBMS, a policy will be chosen such that it directly
>> maps member function calls.
>
>> For crossing the server/client boundary, a RPC policy will be used.
>> Note that the interface is the same.
>
>> However, it would be beyond the scope here, to give a full overview of
>> that idea.
>
> I see idea, Andreas.
>
> Igor also have told me that he have got idea how to use policies for 
> packets
> in client-server. We have not discuss this yet. But he think about 
> issue
> here.
>
> But we talk now about Tree of Nodes.
> This can be 10-20-30 nodes.
> To send them on server we simply need make protocol for them.
>
> By the way, you have some ideas for RPC implementations?
> For now we simply build packet for each operation we need send on 
> network.

There is only a vague idea, currently.
I did not study the existing solutions.
  This issues will be covered in my approach:
Threads, Concurrency
Atomic messages
Message-Queues,
ObjectID, MemberFuncID, ObjectVersion
flatten, unflatten of arguments.
ActiveObjects (performing asynchronous RPC)
MessageDispatching

When an Object sends a message foo(v) to the remote part, then the 
arguments will be flattened, and a message packet will be composed 
containing OID and FuncID and the stream of arguments. foo()  will 
block until a "return message" arrives in the local message queue send 
from the remote part. The  return value and output arguments will be 
unflattened and  foo() returns to the caller on the local side.

Objects listen to an incoming  RPC by listening to the local message 
queue (as an ActiveObject). Once a RPC has arrived, the corresponding 
call will be performed in an separate thread owned by the object 
(ActiveObject pattern).
Much like the Listener / Acceptor pattern. There is only one internal 
thread for several functions.

Note that for an object, RPC and local calls will perform concurrently. 
The RPC is performed within a separate thread owned by the object 
itself. Before the function returns, it sends a return message to the 
client. When the function returns, it immediately starts listening to 
the message queue for incoming or pending RPC calls from remote clients.


So far the idea. If you have further suggestions, I would like to know!

Andreas

>
>
> -- 
> Best regards,
> Ruslan Zasukhin      [ I feel the need...the need for speed ]
> -------------------------------------------------------------
> e-mail: ruslan at paradigmasoft.com
> web: http://www.paradigmasoft.com
>
> To subscribe to the Valentina mail list go to:
> http://lists.macserve.net/mailman/listinfo/valentina
> -------------------------------------------------------------
>
> _______________________________________________
> Valentina mailing list
> Valentina at lists.macserve.net
> http://lists.macserve.net/mailman/listinfo/valentina
>