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.
>
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.
>