* Re: [Xen-API] Xen API or XM
[not found] <461B839B.2030100@oracle.com>
@ 2007-04-10 13:00 ` Ewan Mellor
2007-04-10 17:00 ` Premjith Rayaroth
0 siblings, 1 reply; 2+ messages in thread
From: Ewan Mellor @ 2007-04-10 13:00 UTC (permalink / raw)
To: Premjith Rayaroth; +Cc: xen-devel, xen-api
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Xen-API] Xen API or XM
2007-04-10 13:00 ` [Xen-API] Xen API or XM Ewan Mellor
@ 2007-04-10 17:00 ` Premjith Rayaroth
0 siblings, 0 replies; 2+ messages in thread
From: Premjith Rayaroth @ 2007-04-10 17:00 UTC (permalink / raw)
To: Ewan Mellor; +Cc: xen-devel, xen-api
[-- Attachment #1.1: Type: text/plain, Size: 2280 bytes --]
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.
>
[-- Attachment #1.2: Type: text/html, Size: 2814 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2007-04-10 17:00 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <461B839B.2030100@oracle.com>
2007-04-10 13:00 ` [Xen-API] Xen API or XM Ewan Mellor
2007-04-10 17:00 ` Premjith Rayaroth
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.