[Vrs-development] Re: gw_svc_call (was Re: [DotGNU]Goldwater Documentation)

[Chris Smith]

On Monday 21 October 2002 18:57, Stephen Compall wrote:
> On gw_svc_call:
>
> 1. you mean explicitly freed, not implicitly. If it was implicitly, the
> user wouldn't have to do anything :)

Quite right too.  Will amend.

> 2. You provide a way to avoid blocking calls with GW_NOREPLY, but this
> method of returning "immediately" provides no reply from the service,
> obviously. I suggest a way to receive a reply asynchronously with a
> callback mechanism. That way, users can avoid the overhead (and clutter)
> of new threads.

Yep.  There is (half) a feature for asynchronous requests and replies.
Basically you specify a GW_ASYNC flag when doing the request.  Later you can 
do a gw_get_reply() call to see if your reply is ready and to get it if it is.
However I never really got it to perform very well, so I put it on a back 
burner....  [suddenly recalls trying to work out how to do reply tracking 
properly last year sitting on a beach in Goa... must find those notes!]
The architecture is a lot more mature now, so I should probably resurrect 
this.

> 3. I don't like the idea of limiting oneself to servers and clients:
> once a connection is established, the server and client should be able
> to make "calls" to each other. Perhaps a GWService might keep a client
> object around, and use this to make those calls. Even better, the
> connected client could be described with a path (local to the service),
> just as the "services" are.

There isn't a connection as such, the communicating processes should be 
viewed as being connected to a opaque cloud within which 'magic' message 
routing is performed.
That said, don't forget (or you may have missed it) that a GWServer may 
call GWServices in other GWServers.  Whilst doing so the 'calling' GWServer 
is acting as a client.... the upshot being there is no real concept of what 
is a client and what is a server other than what the process is currently 
doing.  It's all down to terminology.  What we call a GWClient is merely a 
process that is a temporary part of or is external to the Goldwater 
application (and thus does not provide GWServices but can only call them). 
If you need two or more processes to be able to inter-call each other, make 
them GWServers.

However there is another messaging mechanism on the TODO list (again on the 
back burner as it proves to be less useful initially than peer-2-peer) and 
that is publish-and-subscribe. Using this all processes, including real 
GWClients (which cannot normally receive unsolicited messages) may subscribe 
to subjects and receive messages published to them.  The great thing about 
this mechanism is that you can subscribe and publish to wildcarded subjects 
:o)


Thanks for the comments Steven.
Chris
-- 
Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk