WikibaseLib is a horrible kitchen sink, and I don't want to add more to the mess. So I want to put the usage tracking code into sensible packages. However, I'm a bit at a loss as to how to best split the different responsibilities into packages. Here are some of the communication needs we have, implying which code needs to be shared between repo and client: The client needs to: * load entity data ** need to share entity storage code ** but should not know about EntityContent ** and should have no write access * look up properties by label, and look up labels of items ** need to share term storage code ** no need for write access ** no need for code for constraints checks, etc. ** should not have related related maintenance scripts or schema update code * look up data types for properties ** need to share property info storage code ** no need for write access ** should not have related maintenance scripts or schema update code * load change details ** need to share change table storage code and value objects ** no need for write access ** no need for dispatching logic ** also should not have schema update code * look up sitelinks by page title ** need to share link table storage code ** no need for write access ** should not have related maintenance scripts or schema update code * update notification subscriptions ** need to share subscription storage code ** should not have related maintenance scripts or schema update code So, there are 6 things the client and the repo both need to access. But the write logic, or at least the maintenance logic, should not be bundled with the leaner "read only" package. So I see 12 new packages... dependency hell. So, what to do? Have 6 read level packages, and stuff the maintenance logic into a single package not used by the client? Also ugly. Ideas? -- daniel -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.