Can we have "combined" set_object_to_path function just like get_object_by_path?

[weiqiushi]

Now we have the function get_object_by_path(path: impl Into) -> BuckyResult that gets the object itself directly from the root-state's path.

How about a function like this, providing a set_object_to_path? Put object to noc and set it to a path in root-state
I think it should be common to insert an object into the noc and bind it to the root-state

[lurenpluto]

Currently, root-state is operated through the following two types of interfaces

- op-env

The op-env for root-state can be obtained in the following way

stack.root_state()
stack.root_state_stub()

The limitations of this method of operation are as follows:

1. Can read and write
2. Can only operate within the same zone
   Permission check only determines if it is in the same zone, cross-zone operations are prohibited.

- accessor

You can get the accessor of the root-state in the following way

stack.root_state_accessor_stub()

The limitations of this operation are as follows:

1. Read only
2. Can operate across zones
   The target path must be set with the corresponding permissions, as controlled by rmeta's acl permission mechanism.

Therefore, adding set_object_by_path to the accessor you mentioned is equivalent to providing a mechanism to modify root-state across zones, which conflicts with our design principle "root-state can only be modified in the same zone". If we add a set_object_by_path to the accessor, we need to have a different permission design

[weiqiushi]

From the perspective of a DecApp developer, manipulating data only within zones:

When not using accessor

Storing an object to the root-state:

• Generating an object on native code
• Call non_service().put_object() to store an object to the NOC
• call create_path_op_env() to generate the corresponding op_env
• call op_env.set_by_path() to bind the object id to the path
• call op_env.commit() to commit the changes

Read an object from the root-state:

• Create op_env()
• call op_env.get_by_path() to get the ObjectId
• call non_service().get_object() to get the Object itself

These two operations are the most common operations of writing and reading data in DecApp development.

When accessor is used

the read operation will become:
create_root_state_accessor_stub().get_object_by_path()

This obviously reduces the complexity and understanding cost of the read data code

I mean, is it possible to provide a similar function to make the code that writes data also less complex and less expensive to understand?

[lurenpluto]

From the point of view of improving the ease of use of the interface, adding such an interface as set_object_by_path is certainly a good suggestion, at present, many interfaces of cyfs-stack are still biased towards the bottom, in terms of the upper layer of use, some common operations will be very cumbersome, so we will consider adding some "Greater granularity of interfaces" step by step and easy for users to use

For example, the issue mentioned in #189 , is the optimization of the op-env, in fact, it already contains part of the logic inside your requirements, if this optimization layer is provided, your sequence of operations will also be simplified

Regarding the integration of global-state and non related operations, such as providing set_object_by_path, there is definitely a need to add a separate class of interface to operate, because the current accessor only reads the root-state and does not support local-cache, so set_object_by_path if integrated into the accessor is not very suitable maybe

About how to design set_object_by_path, as well as the issue mentioned in this optimization #189 , we can start a piece of discussion, any comments and suggestions are welcome!