On 08-04-2011 01:45, Dmitry Yemanov wrote: > 08.04.2011 5:57, Adriano dos Santos Fernandes wrote: > >> I do have some raw ideas to make batching on the message and request >> API, changing fetch to not return 100/101 but count of messages, and >> make possible to use input messages where is truly many messages >> concatenated. > > Recently I was thinking about adding a msgCount parameter to the v3.0 > API calls which defines how many messages are in fact contained inside > the given message buffer/length pair. At the very least it could be > handled by the provider's upper levels and save API roundtrips for batch > sends and receives (the former is more important, as the latter is > partially achieved at the remote protocol level). However, it could give > even better effect if the BLR internals are made aware of these batched > messages as well. > Sure. If receives and sends just update the message and continue processing without needing the caller to call the looper again.
> It was just a raw idea and I'm happy seeing your research going into the > same (or similar) direction ;-) > Great. Something I'm thinking is how input batching would work related with output. Can a procedure receive multiple input messages and produce multiple output messages, like is possible to do manually using a request? This is a important point to take, as multiple input messages should not be possible only with "execute" but would need something like "fetch" but to send extra messages... Adriano ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
