The goal of D would be to provide customization to the Grid.
Here are some scenarios wherein this will be useful.
a. I have a servlet that I have integrated with VNC, which provides me a way using which I can let my end users watch their automation on the actual remote machine.
b. I have a servlet which restricts nodes from registering themselves to my grid. Only nodes whose IP addresses are known to me would be allowed to register themselves with me.
c. I have a servlet that keeps track of how many tests were run on a particular node, before deciding to clean it up.
But yes, I agree completely with you. These are pretty complex configurations/specifications which not everyone would want to use. As such these are "Nice to have" features but not something that needs to be absolutely present in the plug-in.
So I think we can live with the fact that the Jenkins selenium plugin wouldnt provide for such features.
So for now D and E can be skipped and even then this plug-in would be an awesome way for end-users to make use of.
Btw, the following things came up to my mind when you asked me if I had any additional reqs.
Would jenkins inherently let me do the following ?
1. The grid (spawned by the selenium plug-in) hung and needs to be restarted. How do I accomplish that ?
2. One or more nodes (slaves in this case) got hung and needs to be restarted. How do I accomplish that ?
Pardon me for not paying attention to this thread. I was under the assumption that whenever any new comments got added, it would automatically trigger an email, which wasn't the case here
I will be more vigilant going forward.
And yes, I do want to take a look at your delivery, just to atleast get a feel of how jenkins development works in general and if possible provide some small contributions as well.