Should we schedule a meeting on one or both of these topics (APIs and tc.properties)? Seems like a focused meeting on each might be more efficient than email. I'd be happy to set them up.
----- Original Message ----- From: "Tim Eck" <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, September 25, 2007 1:19:51 PM (GMT-0600) America/Chicago Subject: Re: [tc-dev] TC system properties Apologies up front if I create a giant can of worms here, but left uncontrolled this kind of stuff usually gets out of control. Note: this isn't related to decision of where the API goes -- that is a different topic. I'm personally not a big fan of proliferating the use of system properties in the code base (even if they get consolidated to some central class, or set of constants). We created "tc.properties" specifically to avoid using raw system properties. Conceptually there isn't a huge difference between tc.props and regular system properties, it's just a way to introduce one layer of indirection (useful for testing, isolation, different sourcing methods, etc). That said there are at two things that should really remain system properties (tc.config and tc.install-root). Why? They are required for bootstrapping the client and are firmly cemented in the wild IMO. Let me be the first to say that "tc.properties" could use some more attention. Off the top of my head, these are some things could use some work: - The key space for tc.props is completely ad-hoc right now -- Something akin to a constants interface with safety checks built in could fix that - I don't think tc.props are well suited for config modules - The implementation uses a static under the covers So the question I'm really throwing out there is -- Can we unilaterally use tc.props in place of system properties? > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:tc-dev- > [EMAIL PROTECTED] On Behalf Of Geert Bevin > Sent: Tuesday, September 25, 2007 7:47 AM > To: [email protected] > Subject: [tc-dev] TC system properties > > Hi, > > I was just reading through the source code and I noticed that the > system properties that are supported by Terracotta are really > scattered around the code base. Wouldn't it be good to create a > TerracottaProperties interface in the 'common' project that > consolidates all these property names as constants? Is 'common' the > correct project for this? Do all the other DSO projects depend on it? > > Thanks, > > Geert _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
