Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of
 SRS0=jZbU=LG=dcrdev.demon.co.uk=dan@srs.kundenserver.de designates
 212.227.126.188 as permitted sender)
Message-ID: <46668438.7010100@dcrdev.demon.co.uk>
Date: Wed, 06 Jun 2007 10:54:00 +0100
From: Dan Creswell <dan@dcrdev.demon.co.uk>
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: SourceAliveRemoteEvent Part II
References: <465C83B4.9020008@dcrdev.demon.co.uk>
 <465D8E2C.7090503@cheiron.org> <46648B68.6030904@Sun.COM>
 <466571AB.4010002@wonderly.org>
In-Reply-To: <466571AB.4010002@wonderly.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Gregg Wonderly wrote:
> Bob Scheifler wrote:
>> Mark Brouwer wrote:
> 
>>> 2) the source must send a SARE as the first event (this is helpful in
>>>    finding out whether callbacks are possible);
>>
>> Your main purpose seems to be finding out if callbacks are possible,
>> to decide whether to switch to an alternate event model.  It's not
>> clear to me how common it is or will be to have deployments where you
>> don't know if callbacks will work.  It's also not clear to me why you
>> wouldn't just use the alternate event model first.
> 
> I think there are several distinct network topologies that make this
> kind of thing happen.  But a predominate example would be that when I'm
> at work, I use the local network and get there directly.  At home, I
> might use a VPN and that might work like the local network.  However,
> for some services which are provided by a company, on the internet, from
> their facilities, people at home would have firewall issues.  Whereas,
> when I am at the "work location", I might see the service direct.
> 

Right so the thing that's been bugging me about all of this is that
these issues are faced routinely by those providing services on the web
that conceptually I'd argue were less rich (complex?) than Jini services.

And they have a bunch of ad hoc hacks and various firewall penetration
techniques that work in some cases and not others etc.  In spite of all
of this the "natural law" that's come out is "don't do this stuff, just
poll and be damned".

So here we are with something more complex that's likely even tougher to
deal with and the question is if we (and others) can't solve the simple
cases do we really stand much chance of doing anything magic for our
more complex case?

Everyone ends up architecting their systems around this using simple
proxying etc in the appropriate places - there's no magic and I don't
think that it's related to them not having movable code for example.

I suspect this comes down to a lot of non-functional aspects like
managing complex hacks, managing people, managing endless configuration,
the trouble with finding a single mechanism that always works etc.  i.e.
 Simplicity wins over anything else.

> So, I think that there are valid deployment scenarios where a dynamic
> decision is a good thing.
>

Obviously, I'd reword that a little and say "where a dynamic decision
would be nice".

It's a simple tradeoff for me - if I can find a neat, easy to build
method which addresses a broad area of the problemspace I'll be happy
but I can't help feeling that if this was do'able we'd have already
sorted the web stuff out and, we haven't.

Cheers,

Dan.