DBUS API Doc: questions/clarifications about stratis-docs HOT 9 CLOSED

General

• as we talked about on irc, hopefully there wouldn't be any long-running operations, but if there were we'd tackle that issue when it arose
• an array is returned with the successfully created (or destroyed) things, and then it's up to the client.
• correct

Maybe @mulkieran or @trgill can answer the other parts? I don't have a ready answer to these...

from stratis-docs.

My answer to 3.0 is that I doubt that it matters much either way.

from stratis-docs.

My answer to 1.1.2. I think you're talking about the situation of our redundancy argument to create_pool. We use a tuple in that case, where the first item is a boolean and the second is an item of the correct type.

from stratis-docs.

My answer to 1.1.2. I think you're talking about the situation of our redundancy argument to create_pool. We use a tuple in that case, where the first item is a boolean and the second is an item of the correct type.

I understand what you are doing, my question is that when the first value of the tuple is False, the second parameter doesn't matter, but from a dbus API usage it must have a value of the correct type.
Any suggested value to represent that which is to be ignored? Yes the value doesn't matter, but for example the accepted dbus convention is that to pass an empty object path one uses a '/' for the object path as you cannot pass an empty string for an object path.

This is one reason I like just passing a hashmap for optional arguments. The additional benefit is you can extend an existing API call without breaking API compatibility or introducing a new method call. Some would argue this is an escape hatch of sorts, but it works :-)

from stratis-docs.

My answer to 3.0 is that I doubt that it matters much either way.

When using an API I think it's nice to have consistency, (eg. result code always in element 0), bikeshedding would be easy here, so I'll defer raising this as an issue if no one else feels strongly about it.

from stratis-docs.

My answer to 3.0 is that I doubt that it matters much either way.

When using an API I think it's nice to have consistency, (eg. result code always in element 0), bikeshedding would be easy here, so I'll defer raising this as an issue if no one else feels strongly about it.

I think we have an equal amount of consistency either way. But it's true that our current consistency is more mathematically sophisticated. I think it hasn't bothered us, because we use tuples to extract the values in the Python code. If you were to implement a more mathematically unsophisticated consistency, I would not object.

from stratis-docs.

My answer to 1.1.2. I think you're talking about the situation of our redundancy argument to create_pool. We use a tuple in that case, where the first item is a boolean and the second is an item of the correct type.

I understand what you are doing, my question is that when the first value of the tuple is False, the second parameter doesn't matter, but from a dbus API usage it must have a value of the correct type.
Any suggested value to represent that which is to be ignored? Yes the value doesn't matter, but for example the accepted dbus convention is that to pass an empty object path one uses a '/' for the object path as you cannot pass an empty string for an object path.

This is one reason I like just passing a hashmap for optional arguments. The additional benefit is you can extend an existing API call without breaking API compatibility or introducing a new method call. Some would argue this is an escape hatch of sorts, but it works :-)

I think defaults are just really easy to come up with, so that wasn't a worry. We have to come up with them in our stratisd code and we do not fail.

from stratis-docs.

@tasleson any outstanding issues or questions left, or can we close this issue?

from stratis-docs.

I've voiced my concerns with the existing API and that we are making the decision to ignore the advice of others on best practices. I said my piece.

from stratis-docs.