Comments (7)
We discussed *.actor-channel-capacity
parameters with @Erigara. It turned out that they aren't actually used anywhere ATM, and were left in order to not overcomplicate DevOps' life for current deployments. There is a chance that these options will be returned in some future (hyperledger/iroha#3364), but it is very unlikely to happen before Iroha 2.0 release. Thus, I will remove them from the config reference.
from iroha-2-docs.
Here is a bunch of questions/proposals I have now.
Use human-readable durations
There are plenty of configuration parameters (usually ended with _ms
suffix) which defines some duration in milliseconds. It would be much more convenient for users to specify them in a human-readable form, like:
- 1 second
- 2 minutes
- 1 hour 5 minutes 3 seconds
- 300 ms
[sumeragi]
block_time = "5 seconds" # instead of 5_000
We could implement our own parser, or use something like humantime
crate
Note: users might always opt-out and specify a number of milliseconds:
block_time = 5_000
Use human-readable byte sizes
Same as for durations:
[torii]
max_transaction_size = "32kb"
[wsv.wasm_runtime]
max_memory = "600 MiB"
See: humansize
- Rust
network
, sumeragi.network
, p2p_addr
etc
There is iroha_config::network::Configuration
, which takes [network]
namespace in the config. It has only actor_channel_capacity
field, and according to my IDE, it is not used anywhere. I guess it was eventually moved to sumeragi.actor_channel_capacity
and was not cleared.
I would like to move torii.p2p_addr
and sumeragi.actor_channel_capacity
into network
or sumeragi.network
namespace.
[sumeragi.network] # or just [network]?
address = "localhost:1339"
actor_channel_capacity = 10
address
or addr
?
There is address
in Peer Ids (iroha_data_model::peer::model::PeerId
, used in sumeragi.trusted_peers
):
[[sumeragi.trusted_peers]]
address = "..."
Should we rename it to addr
or use address
everywhere? I would choose address
.
Split telemetry
Current fields are:
name
url
min_retry_period
max_retry_delay_exponent
file
According to the code, it seems that fields 1..4 are for "substrate" telemetry, and field 5 (file
) is for "dev", "future" telemetry. There is no any conflict/dependency between them.
I propose to introduce substrate
and file_output
(or something like that) namespaces:
[telemetry.substrate]
name = "iroha"
url = "ws://localhost:8080"
min_retry_period = "5 seconds"
max_retry_delay_exponent = 4
[telemetry.file_output]
file = "~/iroha-dev-telemetry"
from iroha-2-docs.
As for the time we could use pretty standard format like ISO 8601. Though I'm totally fine with that humanize if that's convenient and does not introduce any awkward confusions.
Agree with the byte size
Agree with the network
Agree with address
Agree with telemetry, though I'd suggest to reformat that to a configurable/pluggable telemetry,
I'd avoid
[telemetry.file_output]
enabled = true
file = "~/iroha-dev-telemetry"
or
[telemetry]
mode = "file_output"
[telemetry.file_output]
file = "~/iroha-dev-telemetry"
but we might consider addressing that. Alternatively the telemetry could be represented by a separate config file with other, more complicated structure.
from iroha-2-docs.
Use human-readable durations
Use human-readable byte sizes
I can't agree more: that'll help users a lot.
I would like to move torii.p2p_addr and sumeragi.actor_channel_capacity into network or sumeragi.network namespace.
Just "network" sounds good to me.
address or addr?
address
. People would copy and paste these configs, if those are not generated, and the parameters would be more readable.
I propose to introduce substrate and file_output (or something like that) namespaces
Sounds good
Though I'm totally fine with that humanize if that's convenient and does not introduce any awkward confusions.
In my opinion, it depends on the case that is handled. ISO is applicable if and when there are long intervals and parsing for some of them has the potential to be ambiguous, otherwise it may be more distracting.
from iroha-2-docs.
Here is a bunch of questions/proposals I have now.
Use human-readable durations
[sumeragi] block_time = "5 seconds" # instead of 5_000We could implement our own parser, or use something like
humantime
crate
I'm very much against this. I think config should be simple. Just using a suffix on the field name is the simplest thing and something everybody will know how to use. Otherwise, the user has to know what the proper format is and we have to implement our own parser for every field, etc. In this case I find that block_time_ms
is a solution that gives us all the benefits and is the simplest possible
Note: users might always opt-out and specify a number of milliseconds:
block_time = 5_000
This is definitely a no. There should be no opting out because it's ambiguous. Config fields should be unambiguous
Use human-readable byte sizes
Same as for durations:
[torii] max_transaction_size = "32kb" [wsv.wasm_runtime] max_memory = "600 MiB"
again the same, I would rather like to see max_transaction_size_bytes
/max_transaction_size_b
/max_transaction_size_b
from iroha-2-docs.
network
,sumeragi.network
,p2p_addr
etcThere is
iroha_config::network::Configuration
, which takes[network]
namespace in the config. It has onlyactor_channel_capacity
field, and according to my IDE, it is not used anywhere. I guess it was eventually moved tosumeragi.actor_channel_capacity
and was not cleared.
remove actor_channel_capacity
. We don't use actors anymore
I would like to move
torii.p2p_addr
andsumeragi.actor_channel_capacity
intonetwork
orsumeragi.network
namespace.[sumeragi.network] # or just [network]? address = "localhost:1339" actor_channel_capacity = 10
just network
is preferable
address
oraddr
?There is
address
in Peer Ids (iroha_data_model::peer::model::PeerId
, used insumeragi.trusted_peers
):[[sumeragi.trusted_peers]] address = "..."Should we rename it to
addr
or useaddress
everywhere? I would chooseaddress
.
let's go with address
, but preferably we should use {public_key}@@{address}
format
from iroha-2-docs.
Split
telemetry
Current fields are:
1. `name` 2. `url` 3. `min_retry_period` 4. `max_retry_delay_exponent` 5. `file`
According to the code, it seems that fields 1..4 are for "substrate" telemetry, and field 5 (
file
) is for "dev", "future" telemetry. There is no any conflict/dependency between them.I propose to introduce
substrate
andfile_output
(or something like that) namespaces:[telemetry.substrate] name = "iroha" url = "ws://localhost:8080" min_retry_period = "5 seconds" max_retry_delay_exponent = 4 [telemetry.file_output] file = "~/iroha-dev-telemetry"
I don't see a point
from iroha-2-docs.
Related Issues (20)
- Add a cheatsheet HOT 1
- Update the README document for each crate
- Creating the new peers and removing them HOT 1
- Provide a migration guide for configuration from `2.0.0-pre-rc.20` to the new system
- Add CONTRIBUTING.md
- Update Branch Names in Tutorial HOT 1
- Replace `docker-compose` with `docker compose`
- Pin issues to specific Iroha versions HOT 2
- Tracking Issue for Example Repositories
- Rust SDK example repository
- JVM SDK example repository
- Python SDK example repository
- JavaScript SDK example repository
- CLI example repository
- Implement a Request to Fetch Test Case Overview Deletion Data and Update Visibility HOT 3
- Incorrect Commands for Iroha Client CLI in Documentation HOT 1
- Verify all `iroha` repo-related links HOT 1
- Update crate names HOT 1
- Interim review of the Blockchain section HOT 1
- Document usage of the Docker image HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from iroha-2-docs.