river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sim IJskes - QCG <...@qcg.nl>
Subject Re: SimpleJeri
Date Wed, 13 Oct 2010 16:27:06 GMT
On 10/13/2010 06:17 PM, Dennis Reedy wrote:
> Okay, but do realize that once you put something like this into a
> cookbook, it can quickly become _the way_ for those that wish to
> develop services using River.

Ok, you can add a disclaimer notice to that specific page. Otherwise i 
don't care if somebody starts to use river because it was made clear to 
this person that it was easy, and not a lot of infrastructure was 
needed. As soon as they start to code their services in the jini service 
pattern, it will be easy for them to port it to fullblown river.

>> But i sure would like to hear where your specific (dis)approval
>> lies.
>
> I dont have any disapproval, from what I've seen they look pretty
> straight forward and similar to what has been written in the past.

Exactly, but what is different is that we are going to put it on the 
river website, and make it easy for developers to start using river.

> Not sure about errors at this point, just questions. Simple one that
> comes to mind is I'm not sure why you need a JiniComponent
> annotation, seems unnecessary, looks to be just a marker? If the
> client passes in the class, why not just go find that?

If the marker annotation is not present, the classname is used, isn't 
it? By using a marker, you can easily mark different services with the 
same marker, and save some work.

> Also, you may want to consider returning a Future for
> ImportHelper.getInstance().

> If I have the time I'll post back more. Just make sure that what
> you're doing has not already been done with the utilities found in
> the myriad of Jini projects. I know Gregg has done some great stuff,
> I have things in Rio, etc ....

Patches and contributions are welcome! Thanks in advance.

Gr. Sim

Mime
View raw message