Struct grammers_client::client::client::InitParams

pub struct InitParams {
    pub device_model: String,
    pub system_version: String,
    pub app_version: String,
    pub system_lang_code: String,
    pub lang_code: String,
    pub catch_up: bool,
    pub server_addr: Option<SocketAddr>,
    pub flood_sleep_threshold: u32,
    pub update_queue_limit: Option<usize>,
    pub reconnection_policy: &'static dyn ReconnectionPolicy,
}

Optional initialization parameters, required when initializing a connection to Telegram’s API.

Fields

device_model: String

system_version: String

app_version: String

system_lang_code: String

lang_code: String

catch_up: bool

Should the client catch-up on updates sent to it while it was offline?

By default, updates sent while the client was offline are ignored.

server_addr: Option<SocketAddr>

Server address to connect to. By default, the library will connect to the address stored in the session file (or a default production address if no such address exists). This field can be used to override said address, and is most commonly used to connect to one of Telegram’s test servers instead.

flood_sleep_threshold: u32

The threshold below which the library should automatically sleep on flood-wait and slow mode wait errors (inclusive). For instance, if an RpcError { name: "FLOOD_WAIT", value: Some(17) } (flood, must wait 17 seconds) occurs and flood_sleep_threshold is 20 (seconds), the library will sleep automatically for 17 seconds. If the error was for 21s, it would propagate the error instead.

By default, the library will sleep on flood-waits below or equal to one minute (60 seconds), but this can be disabled by passing 0 (since all flood errors would be higher and exceed the threshold).

On flood, the library will retry once. If the flood error occurs a second time after sleeping, the error will be returned.

update_queue_limit: Option<usize>

How many updates may be buffered by the client at any given time.

Telegram passively sends updates to the client through the open connection, so they must be buffered until the application has the capacity to consume them.

Upon reaching this limit, updates will be dropped, and a warning log message will be emitted (but not too often, to avoid spamming the log), in order to let the developer know that they should either change how they handle updates or increase the limit.

A limit of zero (0) indicates that updates should not be buffered. They will be immediately dropped, and no warning will ever be emitted.

A limit of None disables the upper bound for the buffer. This is not recommended, as it could eventually lead to memory exhaustion. This option will also not emit any warnings.

The default limit, which may change at any time, should be enough for user accounts, although bot accounts may need to increase the limit depending on their capacity.

When the limit is Some, a buffer to hold that many updates will be pre-allocated.

reconnection_policy: &'static dyn ReconnectionPolicy

specify the reconnection policy which will be used by client to determine whether to re-connect on failure or not.

it can be one of the 2 default implementation NoReconnect and FixedReconnect;

OR your own custom implementation of trait ReconnectionPolicy.

for more details refer to examples

Trait Implementations

impl Clone for InitParams

fn clone(&self) -> InitParams

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Default for InitParams

fn default() -> Self

Returns the “default value” for a type.