Re: Dynamic stage creation

Nobody has said their opinion about that. :-(  But, it's really an 
important change.  This imply that the coder will not be able any more 
to call directly handler methods!  It's because the handler 
creation/destruction would be totally controlled by SS.  So, the coder 
cannot have a reference on it (or, at least, on the real handler).

Do you think that removing direct method call capability is a major 
constraint?  If yes, I'm wondering how to overcome that?

One main characteristic of direct method calls is that they can return 
value.  To provide the same functionality, we could create this method:

Future enqueueCallback(QueueElement qe);

The difference over direct method calls is that this method is 
asynchronous.  If we want something synchronous, we could create this 
method:

StageIF.invoke(String methodname, Object[] args);

and use reflection to call public methods from the real handler.

This last solution could be implemented synchronously or asynchronously.

What do you think?



Quartz wrote:
>>Like I have said, a handler that is preconfigured outside of the init() 
>>can be dangerous if it is reprogrammed.
>>
>>Also, I think that its better to have an uniform and controlled process 
>>for creating handlers.  This offers many interesting possibilities.  By 
>>exemple, if Sandstorm is totally responsible of creating handlers, we 
>>could instrument a handler, or wrap it behind a proxy.  This will be 
>>important if we support load distribution (that is, stage migration to 
>>other computers).
>>
>>Do you agree about my suggestion?
> 
> 
> I don't have comments. Ask users that expect to pass a pre-instanciated handler.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click