On Mon, 2 Sep 2002 02:45, Huw Roberts wrote:
> >> Rather than this I think I may prefer something simpler - at least
> >> initially. Something like
> >>
> >> BlockContext.register( String topic, String name, Object object )
> >> BlockContext.unregister( String topic, String name )
> >>
> >> Job jobOne = ... get the job somehow
> >> ctx.register( "jobs", jobOne.getName(), jobOne );
> >> ...
> >> ctx.unregister( "jobs", jobOne.getName() );
> >>
> >> The reason for this is that then we don't have to expose SystemManager
> >> to clients and thus we are free to evolve it as we see fit. However it
> >> exposes all the information needed to manage object.
> >> Like?
>
> I have 3 issues:
> 1) The ability to add more than one level of hierarchy beneath the blocks.
> 2) Using an interface will make the client code cleaner and more portable.
> 3) Client code will be hooking into this, meaning we are committed to
> supporting it going forward.
>
> I can live with this for now, but i want to consider how it fits into
> the longer term direction. What I'd like to do, is add a
> ManagementContext interface to Framework, and then have SystemManager
> extend this. That would be the first step towards making the
> functionality available in other containers. Does that sound ok? If
> so, how do we proceed in that direction? If its not too big a deal
> maybe we could skip this intermediate step?
I would still prefer to go with the
BlockContext.register( String topic, String name, Object object )
BlockContext.unregister( String topic, String name )
The reason is that we have discussed that feature in the past without really
coming to any conclusion.
For example, lets consider the things that you may want to do with a
"ManagementContext". Usually you will want to
* register/bind object to name
* unregister/unbind object to name
* get a sub context
* get a list of names bound to current context
* get a object bound with a specific name
This is the exact same sort of operations you may want to do if you wanted to
"remote" an object (via soap, altrmi, rmi, corba, or whatever). It is also
the same set of operations that you would do if you wanted to expose an
object in one application to an object in another application.
In effect, the act of registering into a management context is identical to
registering into any directory service. The manager then either exports all
services in directory or the directory itself is responsible for exporting
services.
Anyway the basic interface you end up with is something like
interface Directory
{
void register( String name, Object value ); /* possibly also have
attribute map here */
void unregister( String name );
String[] list();
Object get(String name);
Directory getSubDirectory(String name);
}
Anyways. A couple of years ago, me Berin and Stefano went through all the
different permutations of this (from a one method interface to JNDI with all
20+ methods + 15 classes). However there is no real way to decide what will
be sufficient for all purposes. Berin - any thing I left out from way back
when?
I would prefer we experiment with this and if in a year or so we come up with
a interface that everyone likes then we can promote that to framework and
deprecate the appropriate methods in BlockContext.
Also the architecture of Phoenix is not really friendly to hierarchy of
multiple layers at this stage so I don't see that as a real hinderance. Maybe
when we see it in action we can change it but until then I think we go with
the simple approach.
Thoughts?
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
