Re: Working from home and docking

Yes
I am aware of the performance issue introduced by RMI calls, but that could 
be sorted out ´by cashing data in both directions and update manually or on 
a scheduled basis.

My idea is to develop my components locally (on a local Merlin environment 
configured to dock to a parent merlin environment).

That way I would transfer my tree transparently without being concerned 
about transitions from remote to local calls.

Is like a CVS for running entities.

... and that's what I am trying to fish ... just development ... no 
deployment

the difference?

in deployment you need at least two main steps a) put the component on place 
b) run it

in docking: just transfer when you are done. And if your component happens 
to be a web service (as it is usual today) we dont need to bother about RMI 
(because that is coming from a design decision)

I can give you a long list of benefits if this feature is added ... but let 
me learn more about the great Merlin.

Cheers
//Maquina

>From: Niclas Hedhman <[email protected]>
>Reply-To: "Avalon framework users" <[email protected]>
>To: "Avalon framework users" <[email protected]>
>Subject: Re: Working from home and docking
>Date: Tue, 19 Oct 2004 00:11:10 +0800
>
>On Monday 18 October 2004 23:49, Samuel Ferrer wrote:
> > Guys
> > I wander if is possible to have a Merlin tree running in my machine and
> > have it as a remote child of a leaf at some other Merling tree (on 
>another
> > machine).
> >
> > The idea would be to develop locally but still follow a global 
>structure.
> >
> > That would give the oportunity to deploy and test locally and then just
> > transfer a ready solution to the global solution ... no need for config
> > deployment because like I said the local solution would be ready and the
> > global solution would have knowledge of my modules all along.
>
>Not sure exactly what you are fishing for...
>
>But,
>1. As it is now, it is not possible to reach out and lookup/access 
>components
>in other JVMs without some serious implementation of your own behalf. A
>generic solution is not likely to occur "soon", and you would probably also
>have issues with RMI delays in your application.
>
>2. But I have the feeling that you only want you component/block to work in
>the local context without accessing the 'larger' context in your local
>runtime.
>That is indeed what Metro is all about. Any block can be deployed in a 
>larger
>context, without much trouble. Meaning to say, if it works in your local
>context, it will work in a larger application (except for conflict on 
>global
>resources, and stuff like that). The opposite may not be true, since the
>smaller block may be dependent on services that you don't provide in the
>local context. For that, you can create small mock-components that does
>"enough", and rely on Metro to resolve the dependency automatically (i.e. 
>no
>assembly changes) in its larger context.
>
>
>Please provide more information if that answer wasn't clear enough.
>
>Cheers
>Niclas
>--
>    +------//-------------------+
>   / http://www.bali.ac        /
>  / http://niclas.hedhman.org /
>+------//-------------------+
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [email protected]
>For additional commands, e-mail: [email protected]
>

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.com/