Christopher Browne <[EMAIL PROTECTED]> writes:
> CORBA would definitely support this sort of thing; probably the
> preferable approach would be to pass around sets of information as
> "sequences," which are usually represented as arrays of whatever
> structure is being referenced.
>
> If we have a transaction:
> struct transaction {
> string GUID;
> string description;
> date TxnDate;
> .... and more fields ...
> };
> it is perfectly natural to represent:
> typedef sequence<transaction> TransactionList;
I must admit that I've never actually worked with CORBA; I should go
get an intro to CORBA book. However, this definition looks remarkably
like a SunRPC definition :)
> The notion that an RPC scheme needs to be inefficient because
> transferring 2000 transactions requires the overhead of 8000
> back-and-forth network transfers is Just Silly; a reasonable
> design should certainly be able to transfer a bunch of data at
> once.
Agreed. Hense my original statement.
> The thing that makes life a bit more complicated is that we
> might want to have limits on how many of a [thing] should be grouped
> together...
Hrm, interesting... I'm not convinced that the server should put
inherent limits into what can be querried. However, perhaps we can
break this up into two operations to allow the client to choose
whether it wants to perform the operation. The first RPC returns the
number of splits that would be returned by the second RPC. If the
client actually cares, then it can make the first call to find out how
much to expect.
int32 xaccRpcQuerySplitCount(Query*)
Split **xaccRpcQuerySplits(Query*)
An alternative approach: add to the Query object a "max return" value,
so that a client can set the 'max number of Splits to return'. Then
we don't necessarily need two RPCs; perhaps the Query RPC can return
the actual number of matching splits, even though it only returns the
max number. The only question would be _which_ "max results" should
get returned? ;)
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel