Re: [Freeipa-devel] [RFE] Warnings and client capabilities
I've submitted the updated design document to http://freeipa.org/page/V3/Messages On 10/23/2012 05:57 PM, Petr Viktorin wrote: Here is a draft design document for ticket 2732. Please comment on both the feature itself, and on how to write design documents. Petr¹, please add how the UI should handle this. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] Warnings and client capabilities
On 12/03/2012 07:35 AM, Petr Viktorin wrote: I've submitted the updated design document to http://freeipa.org/page/V3/Messages The use cases section looks strange to me. I do not think that the contents belongs there. The purpose of the Use cases section is to describe usage scenarios in more formal 1-2-3 form. For example: - User open UI - User navigates to page X - User enters Z - User clicks Y Current behavior: - One error/warning message is displayed New behavior: - A message box with several warnings and errors appears at the top of the screen giving user a full overview of what is wrong with the input. Similar use cases should be created for CLI What you have there is valuable info, it just belongs to some other section. On 10/23/2012 05:57 PM, Petr Viktorin wrote: Here is a draft design document for ticket 2732. Please comment on both the feature itself, and on how to write design documents. Petr¹, please add how the UI should handle this. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] Warnings and client capabilities (Was: [PATCH] 0062 Don't crash when server returns extra output)
On 10/29/2012 09:22 AM, Jan Cholasta wrote:
On 26.10.2012 16:35, Petr Viktorin wrote:
On 10/25/2012 04:55 PM, Jan Cholasta wrote:
Hi,
On 23.10.2012 17:57, Petr Viktorin wrote:
Here is a draft design document for ticket 2732.
Please comment on both the feature itself, and on how to write design
documents.
Petr¹, please add how the UI should handle this.
== Ticket summary ([https://fedorahosted.org/freeipa/ticket/2732
#2732]) ==
Currently the only way to display a warning on client is to raise
NonFatalError. This is not particularly good, as it mutes normal
command
output and only one warning can be displayed at a time.
Provide a mechanism for displaying arbitrary number of warnings and
other messages on clients along with the normal command output.
== Additional problem ==
The client validates the response it receives from the server. If it
gets any extra items, the validation fails. Relaxing our validation is
not an option. To support older clients, we need a mechanism for
backwards-incompatible extensions to the API.
== Solution ==
=== Backend ===
Introduce a capability mechanism for backwards-incompatible API
changes. The first capability will be warnings: a client with this
capability can get an extra key in the response dictionary, warnings,
which contains a list of non-fatal error messages.
Capabilities are determined by API version. The version is linear;
it is
not possible for a client to support any custom subset of capabilities.
If a client does not send an API version number, we will assume this is
a testing client (such as a curl from the command line). Such a client
is assumed to have all capabilities, but it will always receive a
warning saying that forward compatibility is not guaranteed if the
version number is not sent.
I think this has potential to break stuff. An old client unaware of
capabilities might not send version and as a result receive unexpected
data, which might trigger some error.
Our client always sends the version. We already use it to detect clients
that are too old or too new. Clients that do not send it are not
protected from breakage. They are not using the API correctly.
Also, if any other clients currently exist, they're unlikely to validate
the results as strictly as we do, so an extra warnings entry shouldn't
hurt them.
It's better to be safe than sorry, IMHO.
What I'm proposing is just adding a warning when the client doesn't call
the API correctly (it did happen to work before if you were lucky --
there was just no protection from incompatible server versions).
I really don't see how this could cause any major trouble.
And I like easy RPC calls too much :)
Capabilities will be recorded in API.txt. When a new one is added, the
API version must be incremented.
All Commands will be updated to explicitly list 'version?' as one of
their options in API.txt (most already do, and all take it).
A missing version option will be set as part of validation/filling in
defaults, so execute() will always get it.
Helper methods will be available for checking a capability and for
adding a warning to the result:
add_warning(version, result, _(What you're doing is a bad idea))
will be equivalent to:
if client_has_capability(version, 'warnings'):
result.setdefault('warnings', []).append(_(What you're doing
is a bad idea))
Here's a couple of things to consider:
* There should be an API that doesn't require the version and result
arguments, because they might not be at hand when a warning needs to be
issued (e.g. in pre/post command callbacks or utility functions).
I don't see how this can be done without introducing global/per-thread
state or reworking the system.
We already use per-thread state frequently, we can use it here as well.
I'm not sold.
Anyway, I think this this is outside the scope of this RFE. It can be
implemented separately when it's needed, on top of the proposed API.
Since it doesn't change the external API we can easily break it into a
separate effort.
Not having access to the output is a limitation of the callbacks. IMO
it's a symptom of a deeper problem: they don't have access to any state
other than what the current callbacks need, and we can't easily make
more stuff available to them.
I think this problem is orthogonal to this RFE and should be solved
separately.
(Note: the version is part of options, so callbacks do have acccess to
it.)
* There should be more message levels than just warning. I think it
should be at least error, warning, info.
I have included error here, because currently we can't send more
than one error back to the client, but it might be handy:
# ipa command --opt1 ugly --opt2 uglier
ipa: ERROR: invalid 'opt1': must be an integer
ipa: ERROR: invalid 'opt2': must be at least 10 characters
Unfortunately, XML-RPC doesn't allow any extra data in error messages,
it's just errno and text. So we can't give multiple errors to the client.
XML-RPC
Re: [Freeipa-devel] [RFE] Warnings and client capabilities (Was: [PATCH] 0062 Don't crash when server returns extra output)
On 26.10.2012 16:35, Petr Viktorin wrote:
On 10/25/2012 04:55 PM, Jan Cholasta wrote:
Hi,
On 23.10.2012 17:57, Petr Viktorin wrote:
Here is a draft design document for ticket 2732.
Please comment on both the feature itself, and on how to write design
documents.
Petr¹, please add how the UI should handle this.
== Ticket summary ([https://fedorahosted.org/freeipa/ticket/2732
#2732]) ==
Currently the only way to display a warning on client is to raise
NonFatalError. This is not particularly good, as it mutes normal command
output and only one warning can be displayed at a time.
Provide a mechanism for displaying arbitrary number of warnings and
other messages on clients along with the normal command output.
== Additional problem ==
The client validates the response it receives from the server. If it
gets any extra items, the validation fails. Relaxing our validation is
not an option. To support older clients, we need a mechanism for
backwards-incompatible extensions to the API.
== Solution ==
=== Backend ===
Introduce a capability mechanism for backwards-incompatible API
changes. The first capability will be warnings: a client with this
capability can get an extra key in the response dictionary, warnings,
which contains a list of non-fatal error messages.
Capabilities are determined by API version. The version is linear; it is
not possible for a client to support any custom subset of capabilities.
If a client does not send an API version number, we will assume this is
a testing client (such as a curl from the command line). Such a client
is assumed to have all capabilities, but it will always receive a
warning saying that forward compatibility is not guaranteed if the
version number is not sent.
I think this has potential to break stuff. An old client unaware of
capabilities might not send version and as a result receive unexpected
data, which might trigger some error.
Our client always sends the version. We already use it to detect clients
that are too old or too new. Clients that do not send it are not
protected from breakage. They are not using the API correctly.
Also, if any other clients currently exist, they're unlikely to validate
the results as strictly as we do, so an extra warnings entry shouldn't
hurt them.
It's better to be safe than sorry, IMHO.
Capabilities will be recorded in API.txt. When a new one is added, the
API version must be incremented.
All Commands will be updated to explicitly list 'version?' as one of
their options in API.txt (most already do, and all take it).
A missing version option will be set as part of validation/filling in
defaults, so execute() will always get it.
Helper methods will be available for checking a capability and for
adding a warning to the result:
add_warning(version, result, _(What you're doing is a bad idea))
will be equivalent to:
if client_has_capability(version, 'warnings'):
result.setdefault('warnings', []).append(_(What you're doing
is a bad idea))
Here's a couple of things to consider:
* There should be an API that doesn't require the version and result
arguments, because they might not be at hand when a warning needs to be
issued (e.g. in pre/post command callbacks or utility functions).
I don't see how this can be done without introducing global/per-thread
state or reworking the system.
We already use per-thread state frequently, we can use it here as well.
Not having access to the output is a limitation of the callbacks. IMO
it's a symptom of a deeper problem: they don't have access to any state
other than what the current callbacks need, and we can't easily make
more stuff available to them.
I think this problem is orthogonal to this RFE and should be solved
separately.
(Note: the version is part of options, so callbacks do have acccess to it.)
* There should be more message levels than just warning. I think it
should be at least error, warning, info.
I have included error here, because currently we can't send more
than one error back to the client, but it might be handy:
# ipa command --opt1 ugly --opt2 uglier
ipa: ERROR: invalid 'opt1': must be an integer
ipa: ERROR: invalid 'opt2': must be at least 10 characters
Unfortunately, XML-RPC doesn't allow any extra data in error messages,
it's just errno and text. So we can't give multiple errors to the client.
XML-RPC is not the only transport mechanism we have, so I don't think
this XML-RPC-centric thinking is appropriate. If XML-RPC does not have
native support for this, we certainly can do it some other way.
Regarding the info level, I don't see a use for it. Information is
what the result dictionary already contains.
Debugging comes to mind. My point is that this thing should be
extensible, so should we require a new message category in future, it
can be added easily.
* We have numeric codes for errors, perhaps we should have them for
warnings as well.
Yeah, we can do that for
Re: [Freeipa-devel] [RFE] Warnings and client capabilities (Was: [PATCH] 0062 Don't crash when server returns extra output)
On 10/23/2012 05:57 PM, Petr Viktorin wrote:
Here is a draft design document for ticket 2732.
Please comment on both the feature itself, and on how to write design
documents.
Petr¹, please add how the UI should handle this.
== Ticket summary ([https://fedorahosted.org/freeipa/ticket/2732 #2732]) ==
Currently the only way to display a warning on client is to raise
NonFatalError. This is not particularly good, as it mutes normal command
output and only one warning can be displayed at a time.
Provide a mechanism for displaying arbitrary number of warnings and
other messages on clients along with the normal command output.
== Additional problem ==
The client validates the response it receives from the server. If it
gets any extra items, the validation fails. Relaxing our validation is
not an option. To support older clients, we need a mechanism for
backwards-incompatible extensions to the API.
== Solution ==
=== Backend ===
Introduce a capability mechanism for backwards-incompatible API
changes. The first capability will be warnings: a client with this
capability can get an extra key in the response dictionary, warnings,
which contains a list of non-fatal error messages.
Capabilities are determined by API version. The version is linear; it is
not possible for a client to support any custom subset of capabilities.
If a client does not send an API version number, we will assume this is
a testing client (such as a curl from the command line). Such a client
is assumed to have all capabilities, but it will always receive a
warning saying that forward compatibility is not guaranteed if the
version number is not sent.
Capabilities will be recorded in API.txt. When a new one is added, the
API version must be incremented.
All Commands will be updated to explicitly list 'version?' as one of
their options in API.txt (most already do, and all take it).
A missing version option will be set as part of validation/filling in
defaults, so execute() will always get it.
Helper methods will be available for checking a capability and for
adding a warning to the result:
add_warning(version, result, _(What you're doing is a bad idea))
will be equivalent to:
if client_has_capability(version, 'warnings'):
result.setdefault('warnings', []).append(_(What you're doing
is a bad idea))
=== Frontend ===
In the CLI, warnings will be printed after the normal command
output.Example (from [https://fedorahosted.org/freeipa/ticket/2563 #2563])
# ipa dnsrecord-add --ttl=555 localnet r1 --txt-rec=TEST
Record name: r1
Time to live: 555
A record: 1.2.3.4
TXT record: TEST
Warnings:
It's not possible to have two records with same name and
different TTL values.
The Web UI will display warnings in a modal message box.
Probably the easiest and default solution. I'm also considering
something similar to 'success notification' - a message displayed in a
header for a brief period. It may be better because confirming dialog is
uncomfortable.
On 06/20/2012 03:57 PM, Simo Sorce wrote:
On Wed, 2012-06-20 at 12:47 +0200, Martin Kosek wrote:
On Wed, 2012-06-20 at 11:10 +0200, Petr Viktorin wrote:
On 06/12/2012 02:39 PM, Petr Viktorin wrote:
[...]
We decided off-list that relaxing validation is not the right thing
to do.
A better approach would be to notify the server that the client can
accept extended data (through a header or a version parameter).
So, ticket 1721 is invalid, but we need a better solution to make
https://fedorahosted.org/freeipa/ticket/2732 Provide means of
displaying warning and informational messages on clients possible.
I think that using the existing version parameter (which gets
added to
RPC calls automatically) would be perfect for this.
I agree, API version is exactly what we want. We should not care about
client version or if the client is in Fedora, RHEL or Ubuntu.
Simo mentioned that we don't want to make the API depend on the version
of our client version, so other clients don't need to copy our
versioning scheme.
However, in the version argument we send the API version, not our
client
version. I think other clients should know and advertise what API
version they are using, and the number shouldn't be specific to our
client.
It's the perfect place to learn the client's capabilities from, if
we're
okay with a linear evolution of the API (as opposed to the client
advertising individual features).
Simo, can you comment? Hopefully I didn't mishear anything on the
meeting.
The biggest asset about API version is that we already have this number
available for clients that were already released, we don't have to
backport anything.
I would keep linear evolution of the API version number as is, but it
would be also good to assign new API capabilities with the number and
have a simple way of checking if client has the capability, i.e.
something like this:
def post_callback(self, ..., *keys, **options):
if 'warnings' in
Re: [Freeipa-devel] [RFE] Warnings and client capabilities (Was: [PATCH] 0062 Don't crash when server returns extra output)
On 10/25/2012 04:55 PM, Jan Cholasta wrote:
Hi,
On 23.10.2012 17:57, Petr Viktorin wrote:
Here is a draft design document for ticket 2732.
Please comment on both the feature itself, and on how to write design
documents.
Petr¹, please add how the UI should handle this.
== Ticket summary ([https://fedorahosted.org/freeipa/ticket/2732
#2732]) ==
Currently the only way to display a warning on client is to raise
NonFatalError. This is not particularly good, as it mutes normal command
output and only one warning can be displayed at a time.
Provide a mechanism for displaying arbitrary number of warnings and
other messages on clients along with the normal command output.
== Additional problem ==
The client validates the response it receives from the server. If it
gets any extra items, the validation fails. Relaxing our validation is
not an option. To support older clients, we need a mechanism for
backwards-incompatible extensions to the API.
== Solution ==
=== Backend ===
Introduce a capability mechanism for backwards-incompatible API
changes. The first capability will be warnings: a client with this
capability can get an extra key in the response dictionary, warnings,
which contains a list of non-fatal error messages.
Capabilities are determined by API version. The version is linear; it is
not possible for a client to support any custom subset of capabilities.
If a client does not send an API version number, we will assume this is
a testing client (such as a curl from the command line). Such a client
is assumed to have all capabilities, but it will always receive a
warning saying that forward compatibility is not guaranteed if the
version number is not sent.
I think this has potential to break stuff. An old client unaware of
capabilities might not send version and as a result receive unexpected
data, which might trigger some error.
Our client always sends the version. We already use it to detect clients
that are too old or too new. Clients that do not send it are not
protected from breakage. They are not using the API correctly.
Also, if any other clients currently exist, they're unlikely to validate
the results as strictly as we do, so an extra warnings entry shouldn't
hurt them.
Capabilities will be recorded in API.txt. When a new one is added, the
API version must be incremented.
All Commands will be updated to explicitly list 'version?' as one of
their options in API.txt (most already do, and all take it).
A missing version option will be set as part of validation/filling in
defaults, so execute() will always get it.
Helper methods will be available for checking a capability and for
adding a warning to the result:
add_warning(version, result, _(What you're doing is a bad idea))
will be equivalent to:
if client_has_capability(version, 'warnings'):
result.setdefault('warnings', []).append(_(What you're doing
is a bad idea))
Here's a couple of things to consider:
* There should be an API that doesn't require the version and result
arguments, because they might not be at hand when a warning needs to be
issued (e.g. in pre/post command callbacks or utility functions).
I don't see how this can be done without introducing global/per-thread
state or reworking the system.
Not having access to the output is a limitation of the callbacks. IMO
it's a symptom of a deeper problem: they don't have access to any state
other than what the current callbacks need, and we can't easily make
more stuff available to them.
I think this problem is orthogonal to this RFE and should be solved
separately.
(Note: the version is part of options, so callbacks do have acccess to it.)
* There should be more message levels than just warning. I think it
should be at least error, warning, info.
I have included error here, because currently we can't send more
than one error back to the client, but it might be handy:
# ipa command --opt1 ugly --opt2 uglier
ipa: ERROR: invalid 'opt1': must be an integer
ipa: ERROR: invalid 'opt2': must be at least 10 characters
Unfortunately, XML-RPC doesn't allow any extra data in error messages,
it's just errno and text. So we can't give multiple errors to the client.
Regarding the info level, I don't see a use for it. Information is
what the result dictionary already contains.
* We have numeric codes for errors, perhaps we should have them for
warnings as well.
Yeah, we can do that for consistency's sake:
The warning info will be a dict with the code, name and message (same as
we treat errors in JSON).
In IPA code, warnings will be objects. The classes will live in a new
module, ipalib.warnings, modeled after ipalib.errors.
The add_warning API will become `add_warning(version, result,
BadIdeaWarning())`.
* We might want to integrate this with the standard Python warnings
module http://docs.python.org/library/warnings.html.
That possible, but I don't see what it would buy us.
Also, I think
Re: [Freeipa-devel] [RFE] Warnings and client capabilities (Was: [PATCH] 0062 Don't crash when server returns extra output)
On 10/23/2012 06:53 PM, Dmitri Pal wrote: On 10/23/2012 11:57 AM, Petr Viktorin wrote: Here is a draft design document for ticket 2732. Please comment on both the feature itself, and on how to write design documents. [...] Did you post the design on the freeipa wiki? If so please update the link in the ticket with the URL. Not yet, I'd like to get a review on the list first. I'll put the link in when I post on the wiki. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] Warnings and client capabilities (Was: [PATCH] 0062 Don't crash when server returns extra output)
Hi,
On 23.10.2012 17:57, Petr Viktorin wrote:
Here is a draft design document for ticket 2732.
Please comment on both the feature itself, and on how to write design
documents.
Petr¹, please add how the UI should handle this.
== Ticket summary ([https://fedorahosted.org/freeipa/ticket/2732 #2732]) ==
Currently the only way to display a warning on client is to raise
NonFatalError. This is not particularly good, as it mutes normal command
output and only one warning can be displayed at a time.
Provide a mechanism for displaying arbitrary number of warnings and
other messages on clients along with the normal command output.
== Additional problem ==
The client validates the response it receives from the server. If it
gets any extra items, the validation fails. Relaxing our validation is
not an option. To support older clients, we need a mechanism for
backwards-incompatible extensions to the API.
== Solution ==
=== Backend ===
Introduce a capability mechanism for backwards-incompatible API
changes. The first capability will be warnings: a client with this
capability can get an extra key in the response dictionary, warnings,
which contains a list of non-fatal error messages.
Capabilities are determined by API version. The version is linear; it is
not possible for a client to support any custom subset of capabilities.
If a client does not send an API version number, we will assume this is
a testing client (such as a curl from the command line). Such a client
is assumed to have all capabilities, but it will always receive a
warning saying that forward compatibility is not guaranteed if the
version number is not sent.
I think this has potential to break stuff. An old client unaware of
capabilities might not send version and as a result receive unexpected
data, which might trigger some error.
Capabilities will be recorded in API.txt. When a new one is added, the
API version must be incremented.
All Commands will be updated to explicitly list 'version?' as one of
their options in API.txt (most already do, and all take it).
A missing version option will be set as part of validation/filling in
defaults, so execute() will always get it.
Helper methods will be available for checking a capability and for
adding a warning to the result:
add_warning(version, result, _(What you're doing is a bad idea))
will be equivalent to:
if client_has_capability(version, 'warnings'):
result.setdefault('warnings', []).append(_(What you're doing
is a bad idea))
Here's a couple of things to consider:
* There should be an API that doesn't require the version and result
arguments, because they might not be at hand when a warning needs to be
issued (e.g. in pre/post command callbacks or utility functions).
* There should be more message levels than just warning. I think it
should be at least error, warning, info.
I have included error here, because currently we can't send more
than one error back to the client, but it might be handy:
# ipa command --opt1 ugly --opt2 uglier
ipa: ERROR: invalid 'opt1': must be an integer
ipa: ERROR: invalid 'opt2': must be at least 10 characters
* We have numeric codes for errors, perhaps we should have them for
warnings as well.
* We might want to integrate this with the standard Python warnings
module http://docs.python.org/library/warnings.html.
=== Frontend ===
In the CLI, warnings will be printed after the normal command
output.Example (from [https://fedorahosted.org/freeipa/ticket/2563 #2563])
# ipa dnsrecord-add --ttl=555 localnet r1 --txt-rec=TEST
Record name: r1
Time to live: 555
A record: 1.2.3.4
TXT record: TEST
Warnings:
It's not possible to have two records with same name and
different TTL values.
I would prefer if we did the same thing as we do for errors here, so
that warnings are printed to stderr and can be clearly distinguished
from normal command output:
# ipa dnsrecord-add --ttl=555 localnet r1 --txt-rec=TEST
ipa: WARNING: It's not possible to have two records with same name and
different TTL values
Record name: r1
Time to live: 555
A record: 1.2.3.4
TXT record: TEST
The Web UI will display warnings in a modal message box.
Honza
--
Jan Cholasta
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] Warnings and client capabilities (Was: [PATCH] 0062 Don't crash when server returns extra output)
On 10/23/2012 11:57 AM, Petr Viktorin wrote:
Here is a draft design document for ticket 2732.
Please comment on both the feature itself, and on how to write design
documents.
Petr¹, please add how the UI should handle this.
== Ticket summary ([https://fedorahosted.org/freeipa/ticket/2732
#2732]) ==
Currently the only way to display a warning on client is to raise
NonFatalError. This is not particularly good, as it mutes normal
command output and only one warning can be displayed at a time.
Provide a mechanism for displaying arbitrary number of warnings and
other messages on clients along with the normal command output.
== Additional problem ==
The client validates the response it receives from the server. If it
gets any extra items, the validation fails. Relaxing our validation is
not an option. To support older clients, we need a mechanism for
backwards-incompatible extensions to the API.
== Solution ==
=== Backend ===
Introduce a capability mechanism for backwards-incompatible API
changes. The first capability will be warnings: a client with this
capability can get an extra key in the response dictionary,
warnings, which contains a list of non-fatal error messages.
Capabilities are determined by API version. The version is linear; it
is not possible for a client to support any custom subset of
capabilities.
If a client does not send an API version number, we will assume this
is a testing client (such as a curl from the command line). Such a
client is assumed to have all capabilities, but it will always receive
a warning saying that forward compatibility is not guaranteed if the
version number is not sent.
Capabilities will be recorded in API.txt. When a new one is added, the
API version must be incremented.
All Commands will be updated to explicitly list 'version?' as one of
their options in API.txt (most already do, and all take it).
A missing version option will be set as part of validation/filling in
defaults, so execute() will always get it.
Helper methods will be available for checking a capability and for
adding a warning to the result:
add_warning(version, result, _(What you're doing is a bad idea))
will be equivalent to:
if client_has_capability(version, 'warnings'):
result.setdefault('warnings', []).append(_(What you're doing
is a bad idea))
=== Frontend ===
In the CLI, warnings will be printed after the normal command
output.Example (from [https://fedorahosted.org/freeipa/ticket/2563
#2563])
# ipa dnsrecord-add --ttl=555 localnet r1 --txt-rec=TEST
Record name: r1
Time to live: 555
A record: 1.2.3.4
TXT record: TEST
Warnings:
It's not possible to have two records with same name and
different TTL values.
The Web UI will display warnings in a modal message box.
Did you post the design on the freeipa wiki?
If so please update the link in the ticket with the URL.
On 06/20/2012 03:57 PM, Simo Sorce wrote:
On Wed, 2012-06-20 at 12:47 +0200, Martin Kosek wrote:
On Wed, 2012-06-20 at 11:10 +0200, Petr Viktorin wrote:
On 06/12/2012 02:39 PM, Petr Viktorin wrote:
[...]
We decided off-list that relaxing validation is not the right thing
to do.
A better approach would be to notify the server that the client can
accept extended data (through a header or a version parameter).
So, ticket 1721 is invalid, but we need a better solution to make
https://fedorahosted.org/freeipa/ticket/2732 Provide means of
displaying warning and informational messages on clients possible.
I think that using the existing version parameter (which gets
added to
RPC calls automatically) would be perfect for this.
I agree, API version is exactly what we want. We should not care about
client version or if the client is in Fedora, RHEL or Ubuntu.
Simo mentioned that we don't want to make the API depend on the
version
of our client version, so other clients don't need to copy our
versioning scheme.
However, in the version argument we send the API version, not our
client
version. I think other clients should know and advertise what API
version they are using, and the number shouldn't be specific to our
client.
It's the perfect place to learn the client's capabilities from, if
we're
okay with a linear evolution of the API (as opposed to the client
advertising individual features).
Simo, can you comment? Hopefully I didn't mishear anything on the
meeting.
The biggest asset about API version is that we already have this number
available for clients that were already released, we don't have to
backport anything.
I would keep linear evolution of the API version number as is, but it
would be also good to assign new API capabilities with the number and
have a simple way of checking if client has the capability, i.e.
something like this:
def post_callback(self, ..., *keys, **options):
if 'warnings' in version.client_capabilities(options['version']):
