subdividing into smaller repositories for greater granularity

[allan-simon]

Hello again

I've recently "copy/pasted" your repository and started to adapt it to create a "server side" version of the xmpp stream structure https://github.com/allan-simon/rust-xmpp-server-stream. I've done so instead of simply using your lib as a dependency because the base things I needed (xmpp socket etc.) are privates.

soon after i was thinking about simpling putting them as public but then i was wondering that maybe as one of Rust use case is embedded/low memory footprint, maybe people would prefer to either have the client lib or the server lib

so i was wondering if it would be a good idea to split this lib into smaller ones, a la node/npm where things are splitted into as small modules as possible to permit a greater reusability.
Of course the main disadvantage would be that it may complicate a little the development.

[Florob]

I'm not as such opposed to splitting some modules off into separate standalone crates, if they are useful on their own. However, that is where I draw the line. I'd be perfectly fine splitting off e.g. the stanza module I recently added into a separate crate. XmppSocket in particular is however an implementation detail of XmppStream to me, and not public for that very reason. It is just a trivial ~30 LOC wrapper around other types, and not very useful on its own. That is below my threshold for warranting a separate crate.
At this point this project is largely a testbed for RustyXML's API, though I do want to turn it into a usable XMPP library in the long run. I'm fine with you reusing parts of it, but I won't make any promises that I'm not making major changes to the code and API.
As an aside, I see you are still referencing RFC 3920, which has been obsolete for 3 years now. Please have a look at RFC 6120, which also happens to be a bit easier to read.