Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of calum.shawmackay@gmail.com
 designates 209.85.218.15 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=ffvfduD1spUoJZdpXAQtEyc10vfArulYsoBiOYkNE9GosuxJjo7w968LVb9xwpZpQY
         MzoKniVL1o/c+Ni8eQ9OY4KV5O9Y1+rqntVPsHHJcdFFzC/KAhyeiXbBtbnWZ8Qfr+mR
         a4Ncw8gEbGNRTUWdpMhTmAh41Vs42udkKD2gw=
Message-ID: <4aa658780812110305j3750332bxfad6bcee22e6d324@mail.gmail.com>
Date: Thu, 11 Dec 2008 11:05:50 +0000
From: "Calum Shaw-Mackay" <calum.shawmackay@gmail.com>
To: river-dev@incubator.apache.org
Subject: Re: Split JavaSpaces and JINI
In-Reply-To: <9b694b200812110254w771fc7f8xfea19b574f51bfbb@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <964EAC824495234A86F3C47DA8BD8AAD17750A@sucden-exch.sucden.co.uk>
	 <493E9460.1030901@wonderly.org>
	 <caf30e2a0812091807u20b45c02yfd69108259902d12@mail.gmail.com>
	 <493FEAA1.7030708@cox.net>
	 <caf30e2a0812101858t1fba4351q907c0c5d5a3c4f5d@mail.gmail.com>
	 <9b694b200812110126t2e14f5cg5d4f46607674111d@mail.gmail.com>
	 <4aa658780812110136v10bd3a77v306114a391c39c4d@mail.gmail.com>
	 <9b694b200812110202v71c722eeh9a4553d28e61df23@mail.gmail.com>
	 <4aa658780812110210k7d0e5f53g5d705cc4327e819a@mail.gmail.com>
	 <9b694b200812110254w771fc7f8xfea19b574f51bfbb@mail.gmail.com>

But I'm not talking here about containers... the stuff in the core
toolkit allows you to write
both services and clients, what I'm getting to, is that we shouldn't
have to rely on containers to
swell the numbers of the converted

2008/12/11 Jools <joolski@gmail.com>:
> 2008/12/11 Calum Shaw-Mackay <calum.shawmackay@gmail.com>
>
>> <snip/>
>> We all have to go back to where we were when we started and think
>> about the end to end process that gave us that 'woah that's cool, I
>> need to look into this technology more' moment and progress that as
>> one of the core goals, not saying it is the highest priority goal, but
>> I get the feeling that we don't care about new people coming to Jini
>> or about their first-steps experience
>>
>
> And what I was saying earlier was that perhaps we shouldn't. (shock horror!)
>
> We've been trying to 'make it easier' for as long as I can remember. Looks
> like that approach isn't working out as we expected.
> However, there are lots of containers and toolkits out there which do make
> using jini easier. And to be honest that's where the expertise should be.
>
> The Core concepts for the jini toolkit are there to manage all the nasty
> network stuff, and make the it visible to the user of the toolkit.
> No hiding of exceptional situations, forcing you to deal with the worse case
> first. It's all there.
>
> Lets bring the core toolkit up to snuff, make it more manageable for the
> toolkit writers and lets focus on adding functionality to core jini code.
> Let the service container/toolkit writers provide the ease of use, which
> they will.
>
> --Jools
>