You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Tom Hobbs <tv...@googlemail.com> on 2010/10/12 17:24:07 UTC
Extras (Was: PGP)
Sim has just reminded me of something I meant to bring up earlier.
> Giving some thought to a remark one of the mentors made, we are discussing all kinds of nice features,
> but we are nowhere nearer to convincing others to use river for their projects.
The way I've described River in the past has been as Lego bricks. To
my mind, River is the very small Lego bricks; the ones that you can
use to build absolutely anything you want. In my opinion, (and also
in my experience), Application Developers don't want very small Lego
bricks. They want door pieces, hinges, long bits, Lego motors and
little Lego monkeys. River certainly doesn't supply any of those, if
you want a hinge, then you can use the little bricks to make one and
everyone has to make their own hinges.
I hope I'm not going to get flamed for saying that a River
distribution should include some pre-built (lego) assemblies.
Probably in a separate JAR(s).
A while back, Sim and I can up with the idea of having an "extras"
package (or entirely new source directory) for such things to go in.
I've made a start with a self-healing proxy in a skunk branch - it
just needs documentation now. I've got a few other ideas of things to
put in here and of course more ideas/contributions are always welcome.
Convincing people to use something is always easier if you can give
them free stuff. While it's true that you get a *lot* of really good
free stuff with River/Jini, it tends to be lower level, i.e. not
Application Level, stuff. When starting out with River/Jini, because
there is so much going on, it can be difficult to see the wood for the
trees. I think working on some of this "extras" stuff (and
documentation, tutorials etc) might be enough of a sweetener to get
other people using it.
If we were to vote, I'd put this and bug fixes to be the focus for the
next release. But I'm curious to see what other people's opinions
are.
Cheers,
Tom
P.S.
I'm not saying that it's unimportant or not useful - and this is just
my personal opinion/experience; I've never encountered the need to
invoke untrusted/unknown services over the Internet. I've only every
been involved in projects where any available services could be
trusted (they were all on internal subnets, or connected over VPNs
etc). Also, as I've recently demonstrated, I'm not a security expert.
:-)
Jini/River is already very customisable and as such can be an utter
headache to start implementing or debug the setup. So of course,
these pluggable security bits your guys are designing and discussing
are going to be really well documented to make them easy to drop
in/pull out as needed. Right? ;-)
Re: Standard Annotations for Jini Deployment (Was: Extras (Was: PGP))
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 10/14/2010 11:04 AM, Greg Trasuk wrote:
>
> On Thu, 2010-10-14 at 11:10, Gregg Wonderly wrote:
>> The same service can then be deployed into other containers if those containers
>> support the River standard mechanisms by looking at deployed service classes for
>> an interface/abstract class and then calling methods appropriately.
>>
>> Any suggestions on what kind of API we need? I have some thoughts, but perhaps
>> others have already done this themselves?
>>
>> Gregg Wonderly
>
> The one thought I have is that we should probably favour a set of
> annotations (a-la-EJB) rather than a service interface.
What I am trying to think about regarding annotations, is the static
"information" annotations provide vs some of the dynamic information that flows
between services and containers.
Maybe you (and others) can elaborate a bit on how you view annotations being
used in River?
Using it to mark methods for particular uses, as you might use an interface, can
work in many cases, but specific information returned from methods needs to
match the expectations of the receiver, and so I worry that some aspects of
annotations are not as concrete as might be necessary.
The other issue for me, is that sometimes people overuse annotations to try and
fit existing code into a new use, and end up with a layer of meta-control, that
would better be expressed in a proxy/delegate object to keep it out of view of
places where it doesn't matter.
But, please let me know your view and everyone else can jump in with their ideas
to help get something going.
Gregg Wonderly
Standard Annotations for Jini Deployment (Was: Extras (Was: PGP))
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Thu, 2010-10-14 at 11:10, Gregg Wonderly wrote:
> The same service can then be deployed into other containers if those containers
> support the River standard mechanisms by looking at deployed service classes for
> an interface/abstract class and then calling methods appropriately.
>
> Any suggestions on what kind of API we need? I have some thoughts, but perhaps
> others have already done this themselves?
>
> Gregg Wonderly
The one thought I have is that we should probably favour a set of
annotations (a-la-EJB) rather than a service interface. I have a
service interface from Harvester that I'd be happy to move over into
'net.jini' and contribute (as I'm sure Gregg has, and Dennis has, and
Mark, etc), but I think EJB3 showed the vast superiority of an
annotation-based approach over an interface approach.
I'm pretty sure somebody already did this for their own project. If
you're there, could you point us to it?
Cheers,
Greg Trasuk
--
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com
Re: Extras (Was: PGP)
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 10/14/2010 6:47 AM, Tom Hobbs wrote:
> Having said that, what I'd like to do with these Extras is to allow an
> AD to download River and have a Jar and/or cookbook which they can
> easily read to get them going. As it stands, justing writing a "Hello
> World" service is not documented on the River site or made easy - and
> it should be. I don't want to take anything away from all the
> fabulous external projects built on top of River/Jini, but as a AD
> myself, I don't want to have to download River and then be told that I
> need to make another decision about which external project I need to
> download next in order to write effective River services. Then I need
> to learn how to knit the two together.
What I think we need to deal with, is trying to map out this Kniting process as
it would exist today given that we have in the community projects and river.
There are the low level service and client construction steps that just use JERI
raw. There is com.sun.jini.start that lets multiple services run
"independently" in the same VM. This is the River container. Then we have other
value added containers such as Rio and Seven as standalone environments, and
still others that integrate Jini into web service environments and other such
environments. There are outliers, like my http://startnow.dev.java.net project
that just provides a giant class that you can subclass, which has all of the
"River stuff" (config, jeri etc) visible in it, so that people can just create a
service with
public class MyService extends PersistentJiniService { }
and call startService("Service Name", "archive.ser") to advertise it. The
things that you need done are done for you. If you want to see how they are
done, "Use the source Luke".
What I feel is really needed, is an interface that all of the "containers" can
support to allow service injection. There needs to be a River SPI that which
allows service authors to create standalone services using simple mechanisms
like those in com.sun.jini.start, but also allows the same service to be
deployed into environments such as Seven, Rio and the web service containers as
well.
It doesn't need to be all powerful, but something basic needs to exist in River
as the "way" which allows these other environments to use those services, even
if it is with some restricted behaviors/features.
Then, there will not be "pain and agony" to switch containers.
The JavaEE world has such mechanisms and people can switch things around there,
because those "services" are the same kind of services doing the same kinds of
things.
Jini is not so "confined" in use, and so we need to step back and think about
whether what matters is the four things that com.sun.jini.start needs, policy,
classpath, codebase and args (ConfigurationFile conveyance path), or is it a
different thing.
The service is the serivce. Those 4 things are deployment considerations and
the things that the "container requires".
Other containers provide automated or more GUI based deployment controls which
don't need the same deployment "mechanisms".
From my perspective, Policy, classpath and codebase are external deployment.
Configuration and command line arguments are runtime deployment information
which can control how the service behaves directly.
So, I'd like to suggest that there is a runtime deployment control mechanism
needed which just deals with "what is the service object", "what is the
configuration" and "what are the arguments". Additionally, the service needs to
have lifecycle management available so that it can know when it is being
unloaded, and perhaps when Policy and Principal information changes so that it
can drop references to cached values dealing with such issues.
If a single Jini service class is "Ran" via 'public static void main()' it
should be able to find a deployment factory instance from "River", and start
itself up.
If a collection of services need to be run in the same JVM, the same service
should be able to be dropped into com.sun.jini.start mechanisms and work.
The same service can then be deployed into other containers if those containers
support the River standard mechanisms by looking at deployed service classes for
an interface/abstract class and then calling methods appropriately.
Any suggestions on what kind of API we need? I have some thoughts, but perhaps
others have already done this themselves?
Gregg Wonderly
Re: Extras (Was: PGP)
Posted by Tom Hobbs <tv...@googlemail.com>.
> Sounds like it should be it's own (sub-)project.
That's a good point.
>> Yes, I agree that the services do not use these utilities, but that's
>> missing the point. In my view, these utilities should *not* be used
>> by the services anyway.
> Well, I disagree. What better way to enforce and test the use of utilities than having River itself use them?
Because (in my mind at least) these utilities lie in some kind of
middle tier; where River is the lower tier, and the business-specific
application stuff is the higher tier. These utilities make it easier
- when going from high --> low.
>> I agree again here, but again with a caveat. I would like to see a
>> lot more chatter going on between as many of those external projects
>> and River as possible.
>
> I'd suggest that this has already been happening. I'm here am I not? :)
Fair point.
> With all due respect I think you're missing the point. The issue here is that many of the things that you wish to accomplish have most likely been done across the myriad of Jini projects that have been out there for years. The reason these projects have been created is "to make it easy and obvious to application developers". Historically, the Jini community at large seems to have a hard time recognizing and endorsing external projects, I dont know why, it just has. What I am seeing here is an opportunity to leverage the work that has been done to move River forward in a better way.
I see your point, but let me mention my concern - then the community
can let me know if that concern is valid or not. I'm prepared to
believe that it's overstated, but not 100% convinced yet. Imagine
you're someone evaluating an SOA for your green field project, you've
heard of River so come to the site to find out more. I'm concerned
(maybe that is to strong of a phrase) that if the entire River
documentation consists of the Jini specs and a cookbook which says "To
do this, download that project. To do something else, download a
different project." then that's going to put people off taking up
River. And I think it short-changes River, in that some of these
things may come across as appearing that in order to do X, you
actually need to download River AND project Y - when actually, you
*could* do all of X just with River.
Strangely, I don't have a (emotional?) problem with people coming from
the opposite direction. They arrive at External River Project A,
think that it looks good and then notice that they also have to
download River as a dependency for that project. To me at least, and
I'm happy to be told I'm being crazy, the above paragraph feels like
it's going to drive new developers away from River, where as the
beginning of this one feels like people adopting River - albeit "under
the covers".
I guess it depends on where in the application stack you consider
River to be. If you consider that River *is* just the low level stuff
and in order to do neat and interesting things with it then you need a
third party application sitting on the top, then you're right. In
which case, this whole "extras" thing is just extra work without any
extra benefit; and we should probably consider abandoning it in favour
of devoting time and effort to supplying extra River features which
make those external projects better.
However, if you consider that River can do neat and interesting things
without a third party component (as I do) then the River site needs
something (code or documentation or both) which shows that. If that
means reproducing features that exist in other third party apps, I
don't actually have a problem with that. It's not my goal to make
those thirty party applications redundant. What is my goal is to make
someone's life, who has no River/Jini background, easier by supplying
a "bunch of stuff" that comes with their River download that enables
them to do a quick (and maybe dirty) proof of concept for their
managers. For me, one of the key parts of the previous sentence is
"comes with their River download" - but maybe that's just me
projecting my own laziness onto everyone else! :-)
> Instead of going out and developing utilities, you could provide a list of capabilities (perhaps creating a call for action), and those that would be inclined to contribute can.
> Alternatively, you may also be pointed to open source projects that allow you to build upon (or leverage/learn) what has already been done.
I have no pressing desire to write a ton of code when other people
might be prepared to donate existing code which does the same thing.
However, in the absence of a contribution, what other option is there?
And I concede in advance that I've not made the details of these
utilities clear or made any request for help - which is why I've not
had any offers yet!
I think the above question of "does River exist just to service
third-party container, or can it be useful on it's own" really needs
answering; because that's going to point us (and this discussion) in
the right direction. What are your thoughts?
I hope this email comes over as friendly (and questioning) - which is
my intention. Rather than argumentative and defensive - which is not
my intention.
Cheers,
Tom
Re: Extras (Was: PGP)
Posted by Dennis Reedy <de...@gmail.com>.
On Oct 14, 2010, at 747AM, Tom Hobbs wrote:
> I think that splitting the platform/services apart and allowing each
> to mature separately is a good idea and one we should do - in fact I
> think that there's been a fair bit of recent discussion about what the
> build artifacts should be.
>
>> Adding utilities at this point seems to be a one-off
>
> I disagree with this bit, because I envisage these "extras" to always
> increasing and maturing as new features arrive in the River code base.
Sounds like it should be it's own (sub-)project.
>
>> and none of the services actually use the utilities (eating your own dog food).
>
> Yes, I agree that the services do not use these utilities, but that's
> missing the point. In my view, these utilities should *not* be used
> by the services anyway.
Well, I disagree. What better way to enforce and test the use of utilities than having River itself use them?
>
>> [1] Lets not also forget that there are plenty of utilities available with external project like Rio, Seven, etc... IMO, failure to look at these as providing
>> utility to the project will be a disservice to the community at large.
>
> I agree again here, but again with a caveat. I would like to see a
> lot more chatter going on between as many of those external projects
> and River as possible.
I'd suggest that this has already been happening. I'm here am I not? :)
> Actually, if external project authors want to drive people to their
> sites, may I cheekily suggest that they write a "How-to" do something
> in plain old River, a How-To do that thing better in their project,
> and then donate the first half of that document to the River site?
>
> If my goal of "make it easy and obvious to application developers" can
> be met with no extra code and just documentation and links to external
> projects, then great. In my opinion though, this appears to imply the
> assertion "if you want to do anything useful in River then you need to
> download an additional external project".
With all due respect I think you're missing the point. The issue here is that many of the things that you wish to accomplish have most likely been done across the myriad of Jini projects that have been out there for years. The reason these projects have been created is "to make it easy and obvious to application developers". Historically, the Jini community at large seems to have a hard time recognizing and endorsing external projects, I dont know why, it just has. What I am seeing here is an opportunity to leverage the work that has been done to move River forward in a better way.
Instead of going out and developing utilities, you could provide a list of capabilities (perhaps creating a call for action), and those that would be inclined to contribute can. Alternatively, you may also be pointed to open source projects that allow you to build upon (or leverage/learn) what has already been done. Consider this includes things like:
Configuration utilities and approaches
Maven archetypes (and support in general)
Smart proxy approaches
Annotations for Jini services
IoC for services you require
(others ...)
Regards
Dennis
> Which is the same
> disservice to River that River ignoring those same external projects
> would be to them.
Re: Extras (Was: PGP)
Posted by Tom Hobbs <tv...@googlemail.com>.
I think that splitting the platform/services apart and allowing each
to mature separately is a good idea and one we should do - in fact I
think that there's been a fair bit of recent discussion about what the
build artifacts should be.
> Adding utilities at this point seems to be a one-off
I disagree with this bit, because I envisage these "extras" to always
increasing and maturing as new features arrive in the River code base.
Certainly, there'll be a large one-off chunk of activity to write a
bunch of the first ones
> and none of the services actually use the utilities (eating your own dog food).
Yes, I agree that the services do not use these utilities, but that's
missing the point. In my view, these utilities should *not* be used
by the services anyway. The ones that I've got in mind sit above the
services and (will) provide easy and convenient ways to allow
Application Developers (AD) to quickly _use_ those services. Sorry if
I didn't make that more clear.
> [1] Lets not also forget that there are plenty of utilities available with external project like Rio, Seven, etc... IMO, failure to look at these as providing
> utility to the project will be a disservice to the community at large.
I agree again here, but again with a caveat. I would like to see a
lot more chatter going on between as many of those external projects
and River as possible. I think a possible reason for the lack of
chatter has been the recent comparative lack of activity on River's
part (and I shoulder my share of the blame for that). Now that River
is starting to gather momentum again, it'd be good if we could put our
collective heads together a bit more.
Having said that, what I'd like to do with these Extras is to allow an
AD to download River and have a Jar and/or cookbook which they can
easily read to get them going. As it stands, justing writing a "Hello
World" service is not documented on the River site or made easy - and
it should be. I don't want to take anything away from all the
fabulous external projects built on top of River/Jini, but as a AD
myself, I don't want to have to download River and then be told that I
need to make another decision about which external project I need to
download next in order to write effective River services. Then I need
to learn how to knit the two together.
What I'd like to see (on the River site and what Sim and I seem to be
trying to work towards) is having some documentation that says, "If
you want to do common use case ABC; look in the extras.jar for class
DEF and use it in the following way." This will get users started
learning how River works, without frustrating them by only supplying
them with the Jini specs and expecting them to just get on with it. I
have no qualms about adding additional text to each recipe in the cook
book saying "... and if you want to do it properly, or in way that has
these additional benefits, then consider downloading project XYZ".
Actually, if external project authors want to drive people to their
sites, may I cheekily suggest that they write a "How-to" do something
in plain old River, a How-To do that thing better in their project,
and then donate the first half of that document to the River site?
If my goal of "make it easy and obvious to application developers" can
be met with no extra code and just documentation and links to external
projects, then great. In my opinion though, this appears to imply the
assertion "if you want to do anything useful in River then you need to
download an additional external project". Which is the same
disservice to River that River ignoring those same external projects
would be to them.
Cheers,
Tom
On Wed, Oct 13, 2010 at 4:47 PM, Dennis Reedy <de...@gmail.com> wrote:
> With the JSK landscape as populated as it is right now with services and utilities, I would suggest that as part of an upcoming release the project starts to breakout the JSK into platform, services and utilities [1] first, before adding additional code.
>
> Consider now we have
>
> Infrastructure/Platform:
> Discovery & Join, Lookup, Leasing, Transactions, Distributed Security, Events
>
> Services:
> Outrigger, Reggie, Mercury, Mahalo, Fiddler, Norm
>
> I would suggest that Reggie be added to the platform, and the rest of the services be put into a services subproject (or module) and allowed to move on their way. Adding utilities at this point seems to be a one-off, and none of the services actually use the utilities (eating your own dog food).
>
> Dennis
>
> [1] Lets not also forget that there are plenty of utilities available with external project like Rio, Seven, etc... IMO, failure to look at these as providing utility to the project will be a disservice to the community at large.
>
> On Oct 12, 2010, at 1124AM, Tom Hobbs wrote:
>
>> Sim has just reminded me of something I meant to bring up earlier.
>>
>>> Giving some thought to a remark one of the mentors made, we are discussing all kinds of nice features,
>>> but we are nowhere nearer to convincing others to use river for their projects.
>>
>> The way I've described River in the past has been as Lego bricks. To
>> my mind, River is the very small Lego bricks; the ones that you can
>> use to build absolutely anything you want. In my opinion, (and also
>> in my experience), Application Developers don't want very small Lego
>> bricks. They want door pieces, hinges, long bits, Lego motors and
>> little Lego monkeys. River certainly doesn't supply any of those, if
>> you want a hinge, then you can use the little bricks to make one and
>> everyone has to make their own hinges.
>>
>> I hope I'm not going to get flamed for saying that a River
>> distribution should include some pre-built (lego) assemblies.
>> Probably in a separate JAR(s).
>>
>> A while back, Sim and I can up with the idea of having an "extras"
>> package (or entirely new source directory) for such things to go in.
>> I've made a start with a self-healing proxy in a skunk branch - it
>> just needs documentation now. I've got a few other ideas of things to
>> put in here and of course more ideas/contributions are always welcome.
>>
>> Convincing people to use something is always easier if you can give
>> them free stuff. While it's true that you get a *lot* of really good
>> free stuff with River/Jini, it tends to be lower level, i.e. not
>> Application Level, stuff. When starting out with River/Jini, because
>> there is so much going on, it can be difficult to see the wood for the
>> trees. I think working on some of this "extras" stuff (and
>> documentation, tutorials etc) might be enough of a sweetener to get
>> other people using it.
>>
>> If we were to vote, I'd put this and bug fixes to be the focus for the
>> next release. But I'm curious to see what other people's opinions
>> are.
>>
>> Cheers,
>>
>> Tom
>>
>>
>> P.S.
>> I'm not saying that it's unimportant or not useful - and this is just
>> my personal opinion/experience; I've never encountered the need to
>> invoke untrusted/unknown services over the Internet. I've only every
>> been involved in projects where any available services could be
>> trusted (they were all on internal subnets, or connected over VPNs
>> etc). Also, as I've recently demonstrated, I'm not a security expert.
>> :-)
>>
>> Jini/River is already very customisable and as such can be an utter
>> headache to start implementing or debug the setup. So of course,
>> these pluggable security bits your guys are designing and discussing
>> are going to be really well documented to make them easy to drop
>> in/pull out as needed. Right? ;-)
>
>
Re: modularizing river
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/30/2010 01:50 PM, Sim IJskes - QCG wrote:
> 5 modules are popping up for me:
> - buildtools
> - jeri
> - extra
> - services
> - test
Hidden under jeri (protocolstack-wise), is ofcourse the library module.
Gr. Sim
Re: modularizing river
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 10/30/2010 02:36 PM, Mike wrote:
>> On 30/10/2010 13:50, Sim IJskes - QCG wrote:
>>
>>> - find,define,declare uni-directional dependencies
>>
>> This was the main focus of my initial explorations, and I found quite a
>> bit of tangled references that make the task not-so-easy.
>
> The build tools and jeri are easily done (i hope). We dont need to
> separate api and implementation here, if you want to distribute an
> alternative implementation you can build a distribution yourself, right?
> Also, the distribution of jeri needs to be done by the system
> integrator, so no download (remote codebase jars) for jeri.
>
> Does anybody see a documentable use for the classdep tool(s) for a
> system integrator? If so we need to distribute it. If not we shouldnt.
It could be broken out as a separate tool, it's useful for determining
dependencies, when you don't know what they are, however if a project is
planned and managed, then the tool is optional. I wonder what Dennis
Reedy thinks?
>
> And as soon as we start with services we need a registry, right? Or
> shall we start with a services modules were we clump everything together?
The registry can be elsewhere, a client only needs the ServiceRegistrar
interface and associated parameter classes (Service API). I like the
idea of service modules, however the Services API's are a separate
concern and theoretically can have multiple implementations. The
service implementations are injected at runtime.
Cheers,
Peter.
>
> FWIW:
> - system integrator: somebody that takes river and adds its own code
> to build a system with it.
> - distribution: binary distribution.
>
> Gr. Sim
>
>
>
Re: modularizing river
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/30/2010 02:36 PM, Mike wrote:
> On 30/10/2010 13:50, Sim IJskes - QCG wrote:
>
>> - find,define,declare uni-directional dependencies
>
> This was the main focus of my initial explorations, and I found quite a
> bit of tangled references that make the task not-so-easy.
The build tools and jeri are easily done (i hope). We dont need to
separate api and implementation here, if you want to distribute an
alternative implementation you can build a distribution yourself, right?
Also, the distribution of jeri needs to be done by the system
integrator, so no download (remote codebase jars) for jeri.
Does anybody see a documentable use for the classdep tool(s) for a
system integrator? If so we need to distribute it. If not we shouldnt.
And as soon as we start with services we need a registry, right? Or
shall we start with a services modules were we clump everything together?
FWIW:
- system integrator: somebody that takes river and adds its own code to
build a system with it.
- distribution: binary distribution.
Gr. Sim
Re: modularizing river
Posted by Mike <mi...@gmail.com>.
On 30/10/2010 13:50, Sim IJskes - QCG wrote:
> - find,define,declare uni-directional dependencies
This was the main focus of my initial explorations, and I found quite a
bit of tangled references that make the task not-so-easy.
> Any suggestions? One request, during the discussion can we talk about
> generic module names, instead of jar or package names?
Yes, please!
--
mike morris :: mikro2nd (at) gmail (dot) com
http://mikro2nd.net/
http://mikro2nd.net/blog/planb/
http://mikro2nd.net/blog/mike/
This email is [X]bloggable [ ]ask-first [ ]private
modularizing river
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/30/2010 04:15 AM, Peter Firmstone wrote:
> Thanks Mike,
>
> I've had some thoughts about breaking the build into components
> something like this:
In order to make it easy for the people working on the build and ci
scripts, some preferences here:
- make as few modules as possible
- find,define,declare uni-directional dependencies
When the dependencies cannot be described in one direction only, either
refactor or don't split over 2 modules.
5 modules are popping up for me:
- buildtools
- jeri
- extra
- services
- test
Any suggestions? One request, during the discussion can we talk about
generic module names, instead of jar or package names?
Gr. Sim
How can we make River's Codebase more managable? (Was: Extras (Was:
PGP))
Posted by Peter Firmstone <ji...@zeus.net.au>.
Thanks Mike,
I've had some thoughts about breaking the build into components
something like this:
jini-platform.jar (net.jini.*, org.apache.river.api.*)
jini-policy.jar
jini-resources.jar
river-lib.jar
river-impl.jar (com.sun.*, org.apache.river.impl.*, common
implementation files)
*service-api.jar (one for each service).
eg:
lookup-service-api.jar
transaction-service-api.jar
lease-service-api.jar
Then all the service implementations proxy's eg:
Reggie-impl.jar
Reggie-proxy.jar
Each component (or module represented here by jar files) could belong to
a separate build, that depends on other components.
The qa-platform would itself be another build, and the tests relevant to
each component would be part of that component, for fast test driven
development.
The minimum requirement for a client would be:
Java 1.5
jini-platform.jar
jini-policy.jar
jini-resources.jar
river-impl.jar
and at least one or more *service-api.jar
If a service download requires another service (which the client doesn't
directly depend) the service proxy can include these files in it's
codebase annotations.
Cheers,
Peter.
Mike wrote:
> On 23/10/2010 12:39, Peter Firmstone wrote:
>
>
>> Mike, are you interested in helping?
>>
>
> Yes I am. Unfortunately it won't be very soon - I am off on business for
> the next couple of weeks. Additionally I would be interested to see more
> discussion on how the codebase should be partitioned than my poor stab
> at it.
>
>
>> It isn't going to be easy, but we need to do it, since it enables more
>> people to work on different distinct components and will reduce the test
>> duration. It takes a whole day to run the tests, not much help for tdd.
>>
>
> Hadn't even thought about that! Good catch.
>
>
Re: Extras (Was: PGP)
Posted by Mike <mi...@gmail.com>.
On 23/10/2010 12:39, Peter Firmstone wrote:
> Mike, are you interested in helping?
Yes I am. Unfortunately it won't be very soon - I am off on business for
the next couple of weeks. Additionally I would be interested to see more
discussion on how the codebase should be partitioned than my poor stab
at it.
> It isn't going to be easy, but we need to do it, since it enables more
> people to work on different distinct components and will reduce the test
> duration. It takes a whole day to run the tests, not much help for tdd.
Hadn't even thought about that! Good catch.
--
mike morris :: mikro2nd (at) gmail (dot) com
http://mikro2nd.net/
http://mikro2nd.net/blog/planb/
http://mikro2nd.net/blog/mike/
This email is [X]bloggable [ ]ask-first [ ]private
Re: Extras (Was: PGP)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Mike, are you interested in helping?
It isn't going to be easy, but we need to do it, since it enables more
people to work on different distinct components and will reduce the test
duration. It takes a whole day to run the tests, not much help for tdd.
Cheers,
Peter.
Mike wrote:
> On 13/10/2010 17:47, Dennis Reedy wrote:
>
>
>> I would suggest that as part of an upcoming release the project
>> starts to breakout the JSK into platform, services and utilities [1] first,
>> before adding additional code.
>>
> ...
>
>> Infrastructure/Platform:
>> Discovery & Join, Lookup, Leasing, Transactions, Distributed Security, Events
>>
>> Services:
>> Outrigger, Reggie, Mercury, Mahalo, Fiddler, Norm
>>
>
> I strongly support Dennis's call for this sort of reorganisation. I've
> had a couple of goes at this in private to test the feasibility, and
> it's not as easy as it sounds... somewhere along the line codebase
> dependencies have become a little tangled, and it's going to be some
> work untangling them.
>
> [Minor] Missing from Dennis's outline above is some sort of "common"
> package for utility classes used all over the place. There certainly are
> quite a number of them.
>
> Also, I would urge that "infrastructure" and "platform" be kept clearly
> separate, where "platform" is essentially net.jini.core so that the
> distinction between "the standards" and "our standard implementations"
> is kept very clear. Might be worth considering moving "infrastructure"
> out from the net.jini namespace altogether (?) (or maybe the distinction
> between net.jini.core and the rest of net.jini is well-enough understood...)
>
> I would also plead for a change in service names (at /least/ for package
> names) to something much more comprehensible. So, for e.g.:
> Reggie -> svcregistry (or just registry...)
> Mahalo -> txnmanager (or transactionmanager...)
> Outrigger -> javaspace
> etc. Much as we might love the old names, they are totally
> non-informative (esp. for newcomers.)
>
> IMHO the codebase is currently too much of a monolith for someone
> approaching it for the first time, and breaking it up into mind-sized
> chunks can only help in getting more people working on the codebase. I
> strongly feel that this monolithic nature has proven too daunting a
> target for many developers over the years - long before Jini became River.
>
> A hard part of this will be refactoring all the tests.
>
>
>> I would suggest that Reggie be added to the platform,
>>
>
> Respectfully I must disagree with this. Registry is just a service.
> Discovery protocol and the requirement for services to announce
> themselves are part of the platform contracts. In theory, at least, it
> should be possible to run some services without reggie in the mix, no?
>
>
Re: Extras (Was: PGP)
Posted by Patricia Shanahan <pa...@acm.org>.
Mike wrote:
...
> IMHO the codebase is currently too much of a monolith for someone
> approaching it for the first time, and breaking it up into mind-sized
> chunks can only help in getting more people working on the codebase. I
> strongly feel that this monolithic nature has proven too daunting a
> target for many developers over the years - long before Jini became River.
>
> A hard part of this will be refactoring all the tests.
Keeping the tests consistent with the source can be handled by setting
up a project in e.g. Eclipse that includes the test source code as well
as the main River source code. Do the repackaging using only Eclipse
refactoring, no direct editing of package statements, and Eclipse will
take care of the tests.
There is an orthogonal issue of examining the category markers in the
.td files to make sure they are helpful. Ideally, we should be able to
tag packages and classes with the test categories that should be run
when they are edited.
I am far, far more concerned about user code. A big upheaval could lose
us users, and make them less likely to recommend River to other users.
Patricia
Re: Extras (Was: PGP)
Posted by Mike <mi...@gmail.com>.
On 13/10/2010 17:47, Dennis Reedy wrote:
> I would suggest that as part of an upcoming release the project
> starts to breakout the JSK into platform, services and utilities [1] first,
> before adding additional code.
...
> Infrastructure/Platform:
> Discovery & Join, Lookup, Leasing, Transactions, Distributed Security, Events
>
> Services:
> Outrigger, Reggie, Mercury, Mahalo, Fiddler, Norm
I strongly support Dennis's call for this sort of reorganisation. I've
had a couple of goes at this in private to test the feasibility, and
it's not as easy as it sounds... somewhere along the line codebase
dependencies have become a little tangled, and it's going to be some
work untangling them.
[Minor] Missing from Dennis's outline above is some sort of "common"
package for utility classes used all over the place. There certainly are
quite a number of them.
Also, I would urge that "infrastructure" and "platform" be kept clearly
separate, where "platform" is essentially net.jini.core so that the
distinction between "the standards" and "our standard implementations"
is kept very clear. Might be worth considering moving "infrastructure"
out from the net.jini namespace altogether (?) (or maybe the distinction
between net.jini.core and the rest of net.jini is well-enough understood...)
I would also plead for a change in service names (at /least/ for package
names) to something much more comprehensible. So, for e.g.:
Reggie -> svcregistry (or just registry...)
Mahalo -> txnmanager (or transactionmanager...)
Outrigger -> javaspace
etc. Much as we might love the old names, they are totally
non-informative (esp. for newcomers.)
IMHO the codebase is currently too much of a monolith for someone
approaching it for the first time, and breaking it up into mind-sized
chunks can only help in getting more people working on the codebase. I
strongly feel that this monolithic nature has proven too daunting a
target for many developers over the years - long before Jini became River.
A hard part of this will be refactoring all the tests.
> I would suggest that Reggie be added to the platform,
Respectfully I must disagree with this. Registry is just a service.
Discovery protocol and the requirement for services to announce
themselves are part of the platform contracts. In theory, at least, it
should be possible to run some services without reggie in the mix, no?
--
mike morris :: mikro2nd (at) gmail (dot) com
http://mikro2nd.net/
http://mikro2nd.net/blog/planb/
http://mikro2nd.net/blog/mike/
This email is [X]bloggable [ ]ask-first [ ]private
Re: Extras (Was: PGP)
Posted by Dennis Reedy <de...@gmail.com>.
With the JSK landscape as populated as it is right now with services and utilities, I would suggest that as part of an upcoming release the project starts to breakout the JSK into platform, services and utilities [1] first, before adding additional code.
Consider now we have
Infrastructure/Platform:
Discovery & Join, Lookup, Leasing, Transactions, Distributed Security, Events
Services:
Outrigger, Reggie, Mercury, Mahalo, Fiddler, Norm
I would suggest that Reggie be added to the platform, and the rest of the services be put into a services subproject (or module) and allowed to move on their way. Adding utilities at this point seems to be a one-off, and none of the services actually use the utilities (eating your own dog food).
Dennis
[1] Lets not also forget that there are plenty of utilities available with external project like Rio, Seven, etc... IMO, failure to look at these as providing utility to the project will be a disservice to the community at large.
On Oct 12, 2010, at 1124AM, Tom Hobbs wrote:
> Sim has just reminded me of something I meant to bring up earlier.
>
>> Giving some thought to a remark one of the mentors made, we are discussing all kinds of nice features,
>> but we are nowhere nearer to convincing others to use river for their projects.
>
> The way I've described River in the past has been as Lego bricks. To
> my mind, River is the very small Lego bricks; the ones that you can
> use to build absolutely anything you want. In my opinion, (and also
> in my experience), Application Developers don't want very small Lego
> bricks. They want door pieces, hinges, long bits, Lego motors and
> little Lego monkeys. River certainly doesn't supply any of those, if
> you want a hinge, then you can use the little bricks to make one and
> everyone has to make their own hinges.
>
> I hope I'm not going to get flamed for saying that a River
> distribution should include some pre-built (lego) assemblies.
> Probably in a separate JAR(s).
>
> A while back, Sim and I can up with the idea of having an "extras"
> package (or entirely new source directory) for such things to go in.
> I've made a start with a self-healing proxy in a skunk branch - it
> just needs documentation now. I've got a few other ideas of things to
> put in here and of course more ideas/contributions are always welcome.
>
> Convincing people to use something is always easier if you can give
> them free stuff. While it's true that you get a *lot* of really good
> free stuff with River/Jini, it tends to be lower level, i.e. not
> Application Level, stuff. When starting out with River/Jini, because
> there is so much going on, it can be difficult to see the wood for the
> trees. I think working on some of this "extras" stuff (and
> documentation, tutorials etc) might be enough of a sweetener to get
> other people using it.
>
> If we were to vote, I'd put this and bug fixes to be the focus for the
> next release. But I'm curious to see what other people's opinions
> are.
>
> Cheers,
>
> Tom
>
>
> P.S.
> I'm not saying that it's unimportant or not useful - and this is just
> my personal opinion/experience; I've never encountered the need to
> invoke untrusted/unknown services over the Internet. I've only every
> been involved in projects where any available services could be
> trusted (they were all on internal subnets, or connected over VPNs
> etc). Also, as I've recently demonstrated, I'm not a security expert.
> :-)
>
> Jini/River is already very customisable and as such can be an utter
> headache to start implementing or debug the setup. So of course,
> these pluggable security bits your guys are designing and discussing
> are going to be really well documented to make them easy to drop
> in/pull out as needed. Right? ;-)
Re: Extras (Was: PGP)
Posted by Zsolt Kúti <ku...@prolan.hu>.
Tue, 12 Oct 2010 16:24:07 +0100 -n
Tom Hobbs <tv...@googlemail.com> írta:
Hello,
> The way I've described River in the past has been as Lego bricks. To
> my mind, River is the very small Lego bricks; the ones that you can
> use to build absolutely anything you want. In my opinion, (and also
> in my experience), Application Developers don't want very small Lego
> bricks. They want door pieces, hinges, long bits, Lego motors and
> little Lego monkeys. River certainly doesn't supply any of those, if
> you want a hinge, then you can use the little bricks to make one and
> everyone has to make their own hinges.
I like this conceit :-)
> I hope I'm not going to get flamed for saying that a River
> distribution should include some pre-built (lego) assemblies.
> Probably in a separate JAR(s).
>
> A while back, Sim and I can up with the idea of having an "extras"
> package (or entirely new source directory) for such things to go in.
> I've made a start with a self-healing proxy in a skunk branch - it
> just needs documentation now. I've got a few other ideas of things to
> put in here and of course more ideas/contributions are always welcome.
I am for one is interested in that self-healing proxy, as have just
arrived to a point being able to value it. And how many similar bits of
wisdom can exist all over in others codebases...
River can benefit from having cookbook-like documentation, too.
Sometimes this is just what is needed to implement something quickly. A
an example was when I wanted to implement an own leased resource. It
has too many aspects to consider which can be daunting for a developer
not too long in the River business.
In my experience, first steps developing and trying out services made
easy by containers (tried Seven/JSC and Rio), which perhaps do not fit
your lego image, but also an important toolbox at our hand.
> Convincing people to use something is always easier if you can give
> them free stuff. While it's true that you get a *lot* of really good
> free stuff with River/Jini, it tends to be lower level, i.e. not
> Application Level, stuff. When starting out with River/Jini, because
> there is so much going on, it can be difficult to see the wood for the
> trees. I think working on some of this "extras" stuff (and
> documentation, tutorials etc) might be enough of a sweetener to get
> other people using it.
Fully agree.
> If we were to vote, I'd put this and bug fixes to be the focus for the
> next release.
Agree once again.
Zsolt
Re: Extras (Was: PGP)
Posted by Tom Hobbs <tv...@googlemail.com>.
I'd prefer to keep them alongside the River distribution, in their own
source tree and/or package.
Would anyone object to the "build distribution" Ant task also building
a "river-extras.jar" which included them. They can then be easily
used or ignored by all and sundry.
Or is that what you meant by "library"?
What I've got so far is already in the SVN (as a skunk branch), I
wouldn't be happy putting them on the trunk without peer review/input.
It's lacking documentation at the moment - that's my job for this
week.
On Tue, Oct 12, 2010 at 4:55 PM, Mike McGrady
<mm...@topiatechnology.com> wrote:
> How about denominating these a "library"?
>
> Sent from my iPhone
>
> Michael McGrady
> Principal investigator AF081_028 SBIR
> Chief Architect
> Topia Technology, Inc
> Work 1.253.572.9712
> Cel 1.253.720.3365
>
> On Oct 12, 2010, at 8:24 AM, Tom Hobbs <tv...@googlemail.com> wrote:
>
>> Sim has just reminded me of something I meant to bring up earlier.
>>
>>> Giving some thought to a remark one of the mentors made, we are discussing all kinds of nice features,
>>> but we are nowhere nearer to convincing others to use river for their projects.
>>
>> The way I've described River in the past has been as Lego bricks. To
>> my mind, River is the very small Lego bricks; the ones that you can
>> use to build absolutely anything you want. In my opinion, (and also
>> in my experience), Application Developers don't want very small Lego
>> bricks. They want door pieces, hinges, long bits, Lego motors and
>> little Lego monkeys. River certainly doesn't supply any of those, if
>> you want a hinge, then you can use the little bricks to make one and
>> everyone has to make their own hinges.
>>
>> I hope I'm not going to get flamed for saying that a River
>> distribution should include some pre-built (lego) assemblies.
>> Probably in a separate JAR(s).
>>
>> A while back, Sim and I can up with the idea of having an "extras"
>> package (or entirely new source directory) for such things to go in.
>> I've made a start with a self-healing proxy in a skunk branch - it
>> just needs documentation now. I've got a few other ideas of things to
>> put in here and of course more ideas/contributions are always welcome.
>>
>> Convincing people to use something is always easier if you can give
>> them free stuff. While it's true that you get a *lot* of really good
>> free stuff with River/Jini, it tends to be lower level, i.e. not
>> Application Level, stuff. When starting out with River/Jini, because
>> there is so much going on, it can be difficult to see the wood for the
>> trees. I think working on some of this "extras" stuff (and
>> documentation, tutorials etc) might be enough of a sweetener to get
>> other people using it.
>>
>> If we were to vote, I'd put this and bug fixes to be the focus for the
>> next release. But I'm curious to see what other people's opinions
>> are.
>>
>> Cheers,
>>
>> Tom
>>
>>
>> P.S.
>> I'm not saying that it's unimportant or not useful - and this is just
>> my personal opinion/experience; I've never encountered the need to
>> invoke untrusted/unknown services over the Internet. I've only every
>> been involved in projects where any available services could be
>> trusted (they were all on internal subnets, or connected over VPNs
>> etc). Also, as I've recently demonstrated, I'm not a security expert.
>> :-)
>>
>> Jini/River is already very customisable and as such can be an utter
>> headache to start implementing or debug the setup. So of course,
>> these pluggable security bits your guys are designing and discussing
>> are going to be really well documented to make them easy to drop
>> in/pull out as needed. Right? ;-)
>
Re: Extras (Was: PGP)
Posted by Mike McGrady <mm...@topiatechnology.com>.
How about denominating these a "library"?
Sent from my iPhone
Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365
On Oct 12, 2010, at 8:24 AM, Tom Hobbs <tv...@googlemail.com> wrote:
> Sim has just reminded me of something I meant to bring up earlier.
>
>> Giving some thought to a remark one of the mentors made, we are discussing all kinds of nice features,
>> but we are nowhere nearer to convincing others to use river for their projects.
>
> The way I've described River in the past has been as Lego bricks. To
> my mind, River is the very small Lego bricks; the ones that you can
> use to build absolutely anything you want. In my opinion, (and also
> in my experience), Application Developers don't want very small Lego
> bricks. They want door pieces, hinges, long bits, Lego motors and
> little Lego monkeys. River certainly doesn't supply any of those, if
> you want a hinge, then you can use the little bricks to make one and
> everyone has to make their own hinges.
>
> I hope I'm not going to get flamed for saying that a River
> distribution should include some pre-built (lego) assemblies.
> Probably in a separate JAR(s).
>
> A while back, Sim and I can up with the idea of having an "extras"
> package (or entirely new source directory) for such things to go in.
> I've made a start with a self-healing proxy in a skunk branch - it
> just needs documentation now. I've got a few other ideas of things to
> put in here and of course more ideas/contributions are always welcome.
>
> Convincing people to use something is always easier if you can give
> them free stuff. While it's true that you get a *lot* of really good
> free stuff with River/Jini, it tends to be lower level, i.e. not
> Application Level, stuff. When starting out with River/Jini, because
> there is so much going on, it can be difficult to see the wood for the
> trees. I think working on some of this "extras" stuff (and
> documentation, tutorials etc) might be enough of a sweetener to get
> other people using it.
>
> If we were to vote, I'd put this and bug fixes to be the focus for the
> next release. But I'm curious to see what other people's opinions
> are.
>
> Cheers,
>
> Tom
>
>
> P.S.
> I'm not saying that it's unimportant or not useful - and this is just
> my personal opinion/experience; I've never encountered the need to
> invoke untrusted/unknown services over the Internet. I've only every
> been involved in projects where any available services could be
> trusted (they were all on internal subnets, or connected over VPNs
> etc). Also, as I've recently demonstrated, I'm not a security expert.
> :-)
>
> Jini/River is already very customisable and as such can be an utter
> headache to start implementing or debug the setup. So of course,
> these pluggable security bits your guys are designing and discussing
> are going to be really well documented to make them easy to drop
> in/pull out as needed. Right? ;-)