Hi Ewan,

Thanks a lot for your answers. This is very informative..

Thanks
-Prem

Ewan Mellor wrote:
> On Tue, Apr 10, 2007 at 06:01:23PM +0530, Premjith Rayaroth wrote:
>
>   
>> Hi,
>>
>> With the introduction of Xen-API, will 'xm' command be deprecated?  .
>>     
>
> No, certainly not.  xm is the human-usable interface into Xend, and as such
> certainly will stay in use going forward.  Think of xm as a CLI tool that uses
> the Xen-API.
>
>   
>> 1. Apart from Remote/RPC calls, does Xen API have more features than 'xm' ?
>>     
>
> Sure.  The biggest feature is that the Xen-API has been designed to be
> extensible and supportable in the long term.  It is the only interface that
> will be guaranteed to remain compatible at the wire-level as we move forward.
> xm has never been like that, has changed many times in the past, and will
> change many times in the future too.  In essence, xm is designed to be used by
> humans, but the Xen-API is designed for scripts and GUIs.
>
> Another notable feature of the Xen-API over xm is the ability to perform
> long-running tasks asynchronously, and to register for and process events
> out-of-band.
>
> Xen-API achieves these things by being more orthogonal in its feature design
> than xm, and more detailed.  Obviously, humans often need a simplified, more
> aggregated view of the world, compared with that offered by Xen-API, and it's
> xm that does this aggregation.
>
>   
>> 2. If I compromise on the remote/RPC feature, can I still keep using 
>> 'xm' for future releases of Xen?
>>
>> 3. Will 'xm' command be deprecated or discouraged as a best practice for 
>> the current/later releases of Xen?
>>     
>
> If you are using xm for scripting purposes, then there is no guarantee that
> things will not break underneath you.  You would be much better off with a
> Python Xen-API script, for example, as this is less likely to break.  You will
> also find it easier to extend your script later to take advantage of new
> features.
>
> xm will not be deprecated in the sense that it represents the human-readable
> interface into Xend, but it's certainly not recommended to build tools against
> it.  Those who've already done so should start an orderly transition over to
> the new API.
>
> Cheers,
>
> Ewan.
>