estan
commented
9 years ago I would vote for keeping the names in the code and the API 100% "session". And let "component" be something more abstract that you use when talking in general about building your applications... I can understand how the two have become somewhat intermingled, but I think it's important that such dualities doesn't creep into the API.
In the API right now it's autobahn.wamp.types.ComponentConfig class, the allowEmptyComponents parameter of the autobahn.wamp.message.check_or_raise_uri method and the documentation of the config parameter of autobahn.wamp.protocol.ApplicationSessionFactory where I think the use of "component" sticks out. (Also the convenience Application and ApplicationRunner I see now..).
oberstet
In almost all examples, and in much of the documentation, the term "session" and "component" are mixed in a slightly confusing way.
E.g. many of the examples:
class Component(ApplicationSession):. This just rhymes bad to me. Why not call the derived classSession? It derives from an AutobahnApplicationSession.I guess you could argue that you build your "component", and that "component" happen to be implemented as an Autobahn
ApplicationSession. But I think naming things are important and would really like to hear why the terms "session" and "component" are mixed like this in the code.I'm itching to call my own such classes
FooSessionandBarSession, to follow the naming of the superclass... but then in the API there'sautobahn.wamp.types.ComponentConfig... Again, why is this called "component"? Isn't it a configuration for an application session? In fact, this is the only class I can find in the public API which is named something with "component". I would expect this class to be called eitherApplicationSessionConfigor justSessionConfig(ifApplicationSessionis to keep its name).