GitHub user erickguan added a comment to the discussion: Do we have better 
names for opendal python's Layer?

Thanks for the invite. @asukaminato0721's investigation is solid.

Popular web frameworks use middlewares. They made that choice for obvious 
reasons — each middleware can add additional features, short-circuit 
executions, and more.
In contrast, deep learning frameworks use layers because the term layer 
originates from multi-layer perceptrons, which are made up of stacked layers. 
OpenDAL has nothing to do with neural network layers, so that analogy isn't 
applicable.

For further reference, 
[scrapy](https://docs.scrapy.org/en/latest/topics/spider-middleware.html) also 
uses middleware.

Some other libraries, such as requests, mainly offer additional configurations 
through extra arguments rather than through configurable middlewares. Since 
OpenDAL has many layers, such a design (relying only on arguments) would be 
less desirable.

Other names, such as Handlers (e.g., logging.StreamHandler), mostly act as 
adapters. They don't align well with OpenDAL's concept of layers either.

While "layers" make sense technically — especially since OpenDAL is 
storage-focused — using "middlewares" would align better with Python ecosystems 
that are common in web applications and CLIs (which interact heavily with 
remote services).
I imagine most users who are interested in the Python bindings will want to use 
OpenDAL to share a unified interface across web services and data applications, 
leveraging its broad support for various storage backends.
In other words, most users would expect the Python binding to serve as a 
convenience layer for building applications, not for building a 
storage/database system itself.

Therefore, I concur with using middlewares — adopting the middleware concept in 
the Python bindings will make OpenDAL more ergonomic and intuitive for users.

GitHub link: 
https://github.com/apache/opendal/discussions/6074#discussioncomment-12956740

----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]

Reply via email to