Am 01.09.2014 20:27, schrieb Jeroen De Dauw: > Hey, > > Great you are looking into this Daniel! > >> So, there are 6 things the client and the repo both need to access. > > These 6 things listed here do not translate into 6 packages. That has to be > considered more carefully.
I absolutely agree. My intention was to point out the naive approach as a baseline, as food for thought. Btw, some interfaces that are currently in lib or repo would be useful to have in the storage level components. Where should these go? A separate WikibaseStorageInterfaces package? >> But the write logic, or at least the maintenance logic, should not be bundled > with the leaner "read only" package. > > I disagree with this being a rule or even something that is extremely > important. > In the end, this is not something we care about directly, and only do to avoid > certain pains. We'd at least need different include files for repo side and client side usage (so schema updates can be hooked in where appropriate). It feels kind of ugly to have that in the actual library. Also, running the maintenance script on the "wrong" side of things will simply fail . So it's not totally critical, but it does seem confusing to me to lump that together. > I'm highly sceptical that such splitting is warranted for > everything, and suggest one first looks at the interface segregation issues > that > plague the data access code. I agree. > Doing this well requires holding into account many more factors than have been > outlined, and is probably better done in a more incremental fashion than > trying > to tackle all these different aspects at once. I agree. But I also think it's useful to have a broad overview. > This makes me think asking the > question in this format on the list is not the best way forward. In person > discussion focusing on a single component is much better IMO. I often find a face to face discussion useful for resolving a particular issue, but for collecting ideas and getting an overview, a broader discussion on a mailing list is useful in my experience. Perhaps we can tackle some of this in the "splitting Wikibase.git" discussion today. -- daniel -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V. _______________________________________________ Wikidata-tech mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
