A good starting point would be to move the unexported marshalling code into an internal package and export just the Marshall / Unmarshall functions from the gocql package

@joao-r-reis I can handle it, but there are a few tricky moments:

1. It would be nice to split gocql by multiple packages, but it will cause issues with backward compatibility, we can use type aliases like in the following PR or merge it to gocql v2.
2. Also, we should decide what exactly we want to move to separate Go packages and what kind of architecture we want. Something could be changed during implementation, but there is a lot of work, so it would be great to have more details on this issue. In my opinion, it would be better to split the project into small packages like the marshal, framer, session, etc. to provide more flexibility and scalability, also it will make it easier to navigate through the project.

What do you think?

I think the project is not that big that it needs a lot of packages, the main purpose of this ticket should be to at least keep the public API stuff on the current gocql package and move everything else to an internal package in ./internal/.... After this then we can think of splitting the internal package into multiple internal packages but I'd focus on just having the gocql package for the public API and a single internal package to start with.

Maybe we could add an internal protocol package for framer and marshal code right away too (maybe a "native protocol package")

Oh keep in mind that since this will change a lot of files it will be hard to keep the PR in sync with all other PRs that are waiting to be merged atm. There will be a lot of work involved in resolving git conflicts.

Ok, I'll start with the framer, and then we can check it as an example

Ok, I'll start with the framer, and then we can check it as an example

It might make more sense to group framer and native protocol stuff in a single package but I'm not sure