BTW I will never rate a project based on the number of classes. This is an implementation issue and if it does not hinder me and does not influence the API I don't care.
Von meinem iPhone gesendet > Am 22.12.2014 um 17:36 schrieb Mark Struberg <[email protected]>: > > Hi! > > I have a very fundamental problem with the current state of Tamaya. It grows > and grows and grows and grows. But what for? What are the key benefits of all > those classes? > > I bet I don't see all the details, so please lets get a discussion started. > > > As a simple start I just like to compare 2 known mechanisms: > > 1.) DeltaSpike > The whole configuration system consists of 5 classes with in summary 800 > lines of code (including license headers, tons of javadoc, etc). > > > 2.) Tamaya > 123 classes with 7500 lines of code > > > So as you can see there is a HUGE difference in complexity. And to be honest > I cannot see much justification yet. > > > > Even if you add the ProjectStage (3 classes, 500 LOC) and the full CDI > integration (4 classes, 400 LOC) to DeltaSpikes configuration (features > Tamaya don't yet have) then you are still way below Tamaya. But even with way > more functionality. > To be honest, I was reading through JavaDocs and sources and so far it was by > far more WTFs than aha. > > > > Of course I most probably miss some features, so please help me to find those > gaps and fill them. > I'd like to suggest that we start a small game and collect use cases and how > those might get solved with Tamaya and with DeltaSpike-config. > > > In general we have to abstract 4 different aspects: > > 1.) the API/SPI > 2.) the server provided functionality > 3.) a user way to customize/extend the configuration functionality > 4.) the user way to read the configured values > > > I'll give you an example of a use case: > > A company uses REST endpoints and need to talk to those. > So we need to configure a few things: > 1.) the endpoint URL > 2.) the username which should be used to connect (e.g. over https, BASIC > auth, whatever) > 3.) the passphrase which should be used to connect. > > The security credentials (passphrase) should not get stored in plaintext but > encrypted using PKI. It should of course also not get logged out in clear > text but shall get masked if logging out the configured values is enabled. > > > In DeltaSpike I'd just register a ConfigFilter to do the password decoding on > the fly. So this is pretty much straight forward. How is this handled in > Tamaya? > > > Now it's your turn: give me some use case where you think the current tamaya > source is strong. And then we gonna discuss it. If something is not needed or > easily solvable otherwise then we gonna drop those parts which are > superfluous. NOW is the time to do such things! If all features and sources > turn out to be there for a good reason than I'm happy to keep them. If there > is no VERY GOOD reason, then it will get cut out. Not sure about the others > around here, but I personally am a really big fan of KISS (Keep It Simple and > Stupid) when it comes to such fundamental (in the sense of important > fundament and foundation) pieces. > > > txs and LieGrue, > strub
