Consider library reorganization

[DanSimon]

This would result in a significant project/package re-organization of the entire framework

What do we hope to achieve?

Goals:

• Fewer wildcard imports needed for most tasks
• Fewer unneeded things imported with wildcard imports
• packages more closely match architecture
• easier to split library into multiple artifacts

Non-goals:

• ?

Caveats:

• A lot of types could end up getting moved to a different package, making upgrading versions more difficult.

How to Categorize Types

Until Recently, many of the lower-level classes and traits were directly exposed to users. They used things like Protocol, Server, ServiceClient, and Codec directly. Now protocols have hidden nearly all those details, so the only people who deal with them are people writing protocols themselves.

The first major split (which sort of already exists) is a sharp divide between protocol-specific code and everything else. We already have protocols separated, but we could take this a step further by making protocols separate artifacts. Thus users would have to explicitly include colossus-http or colossus-redis as dependencies.

Second, we clearly have 2 different types of users.

1. Application developers, people using colossus to build services
2. Protocol/library developers, people using colossus to build libraries

So this means all types can be roughly split into 3 categories

1. Application Types - used by app developers
2. Library Types - used by protocol/library developers
3. Internal Types - only used internally within Colossus

Lastly we could partition types into functional categories

• Types used across the framework (like DataBuffer, Context)
• Types related only to Servers
• Types related only to Clients
• Types only used inside protocols (like parsers, Encoding)
• possibly others...

Package Structure

The way we can organize these could be:

• Application types are all top-level in a package
• Library Types are in a "core" sub-package
• Internal types are also in the core sub-package, but potentially marked private

Now either we can do colossus.<functional_category>.core or `colossus.core.<functional_category>. So we need to decide whether function or user categorization should take precedence.

[benblack86]

An interesting article to provide motivation https://virtuslab.com/blog/zinc-sbt-friendly-code/

[benblack86]

Closing for now as this should be recreated as an RFC.