[Spread-users] spread as a shared library?

[Neil Conway]

Theo Schlossnagle wrote:
> going through the effort of bulding a library that imposes on users that 
> they can only have one "connection to spread" would be disappointing.  
> There are many legimate situations in which it can be advantageous to 
> have multiple sessions from within a single app

Yeah, I agree. I meant that our motivation is that we don't need to 
multiplex multiple clients through a single Spread daemon, but of course 
that's no reason to only allow a single Spread connection per process 
using the library.

> There are many simple configuration file "mistakes" (like leaving one 
> server out of the list on a single machine) that will cause Spread to 
> not work with a non-obious error message.

Yes, Spread error reporting and recovery in general could do with a lot 
of work.

> Also, many common network configuration errors that don't cause
> problems for other protocols can reek havoc on a Spread cluster.

Can you elaborate on what you mean?

> If you do surgery that dramatic, be prepared for a Frankenstein.  I'd 
> recommend a rewrite based on the protocols and concepts.

Yes, I've been considering that as well. It would let us get out from 
under the BSD-with-advertising license (I'd prefer 3-clause BSD), but 
I'm not keen to reinvent the wheel unless there's a compelling reason we 
can't refactor Spread to do what we need.

> It would allow a different messaging API to be used and allow much
> higher performance as you could effectively do zero-copy messaging in
> many cases.
[...]
> This is on our todo list here at OmniTI (along with an epic laundry list 
> of enterprise enhancements).

If you have any TODO items beyond Spread's TODO, feel free to share 
them. We're looking at making a bunch of improvements to Spread anyway, 
but if you've already run into areas where it could be improved that 
would be helpful.

-Neil