Could provide raw "call_chain_extension" function to developer?

[tylerztl]

I think use "chain_extension" need define custom env is complex, it is easy to use raw "call_chain_extension" function.

[Robbepop]

We could expose a raw low-level API in ink_env but why would you need it if ink! provides a safer alternative that covers the entire API?

[atenjin]

currently ink! designed chainextension needs to bind with env, develoepr should provide a custom env to integrate with ChainExtension. But this is not friendly for 3rd parity to provide a library.

For example: if the developer need to use custom chain-extension while use a chain-extension feature from a third parity, he just could write a #[ink::chain_extension] trait and add custom function, and rewrite a function for the 3rd parity interface. If the 3rd parity provide a custom env, then the user could not integate with self custom interface.

But if ink! provide a raw call_chain_extension interface, the 3rd parity could wrap the call_chain_extenion to provide self feature, a nd tell user it's function_id, then, the developer could use the 3rd parity 's interface and self custom chain-extension as well.

The example is our repo ink-log https://github.com/patractlabs/ink-log#example-1

in post ink version, contract could use ink-log directly:

ink_log::info!(".....");
// in the info! macro, it call `call_chain_extension` and hide implementant, user use this macro as normal function.

but for now ink version, developer should set ink_log::CustomEnv, otherwise it would meet compile error.

#[ink::contract(env = ink_log::CustomEnvironment)]
ink_log::info!(".....");
// in this macro, it only could call Self::env().log(...) to do same thing.

But if developer need to use self customenv while log, then the 3rd parity wrapper is useless, developer need to rewrite same thing which is already in the 3rd-parity repo.

[HCastano]

I think this is a bit outdated.

We are able to use custom environments in chain-extension thanks to #1645, and we'll be able to call into the runtime using call_runtime with #1641, giving developers more flexibility.