The DeltaSpike configuration module is very simple. It's smaller than even what I use in my application code (taking out javadocs, headers, etc). I also doubt you're taking into account project stage, etc.
On Mon Dec 22 2014 at 11:38:09 AM Mark Struberg <[email protected]> wrote: > 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 >
