Here are my thoughts:
Experimental driven development is an important part of verifying api,
however multi threaded multicore hardware doesn't lend itself to
experimental development, because there is no way to confirm the
repeatability of the experiment or that the experiment ensures the
abs
(off-list)
Peter:
You’re sounding unprofessional, and you’re missing the fact that people are
giving reasonable and well-thought-out feedback. You seem to be taking the
conversation personally.Perhaps you should take a few hours off the list
and cool down. Things will still be here whe
You just did.
The blue pill.
I prefer the truth, it's easier in the long run.
Feel free to cast your vote.
Peter.
- Original message -
> Peter,
>
> There's so many things wrong in there, I'm not even going to dignify this
> with a response.
Peter,
There's so many things wrong in there, I'm not even going to dignify this
with a response.
- Original message -
> "Comments like `Jini 2.x doesn't seem to have such an issue even with the
> "serious flaw" you
> claim?` are typical of an experimental approach."
>
> They might well be typical but in this case my statement has nothing to
> do with an experimental approach.
>
> [ I
"Comments like `Jini 2.x doesn't seem to have such an issue even with the
"serious flaw" you
claim?` are typical of an experimental approach."
They might well be typical but in this case my statement has nothing to do
with an experimental approach.
[ In fact, you could have asked me if I'm advoca
Pat,
I'd like to invite you back, even if it's just in an advisory capacity.
I think we can all benefit from your experience.
So far you've managed to explain everything so eloquently, the rest of us look
like children fighting over toys.
Regards,
Peter.
- Original message -
> On 12/
On 12/20/2013 1:25 AM, Dan Creswell wrote:
...
And "serious flaw" - really? How might you judge that as the case? Have we
got a serious service-startup problem? Jini 2.x doesn't seem to have such
an issue even with the "serious flaw" you claim? Perhaps this "serious
flaw" has come into being beca
On Fri, Dec 20, 2013 at 8:12 AM, Bryan Thompson wrote:
> Hello, I put together a test to examine what would occur if a local service
> submits an RMI (via jeri) to a remote service.
> (this would be easier if I had a pointer to a pattern for starting and
> killing the child process that I coul
Hi Peter, and list:
A couple of things here -
1 - We’re collaborating on an email list, and we’re pretty evenly spread across
the global timezones, not to mention that River is a part-time pursuit for most
of us. There may be some delay between when a point is made and when anyone
else actu
Hi Bryan:
I would expect the remote task to complete and return, despite the caller being
interrupted. The JERI subsystem (I’m guessing the invocation layer, but it
might be the transport layer) might log an exception when it tried to return,
but there was nobody on the calling end.
That’s c
Hello, I put together a test to examine what would occur if a local service
submits an RMI (via jeri) to a remote service. This unit test setups up a
remote service (in a child JVM) and then issues an RMI that invokes a {@link
Thread#sleep(long)} method on the remote service. The thread that iss
Looks like my mobile mail client deleted the wrong paragraph, my reply was
intended for Greg's belief we needn't concern ourselves with bugs and
refactoring is navel gazing, it was so silly I found myself laughing and
probably didn't notice the wrong paragraph was quoted.
I mean, if I didn't fi
Inline, this time...
On 20 December 2013 06:47, Peter wrote:
> - Original message -
> > On 12/19/2013 12:16 PM, Greg Trasuk wrote:
>
> > And, using, for example, the strategy you describe of constructing
> > another object, code can be perfectly valid without using Startable. I
> > see
A few words stand out there:
"we can still cooperate"
You feel that this:
"Get over your fear people, let us develop, we are maintaining backward
compatibility."
is a demonstration of co-operation? No, that's an order.
"so I can fix a serious flaw with our api?"
I? Not we, I - so are you co-o
Well there's two communities of users, right? Those that use River & those
that want to work on River who've likely been users previously.
In the past we've had some desire to focus on growing the River developer
base to support the River user base which drove the code restructuring
discussion. Fa
16 matches
Mail list logo
