I guess I'm a little confused about what we should have and what we do have. I'm not sure I understand what is meant by "internal API for developing transparency". I'm guessing those are interfaces that we write to internally? I believe that is effectively what is in dso-l1-api now.
For config modules, I think the portions of the api that need to be exposed are a subset of the stuff in dso-l1-api. I don't think this stuff is separable from the prior right now, but I'm not sure of exactly what needs to be exposed. And I think the jar contains the superset of the above stuff. ----- Original Message ----- From: "Steven Harris" <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, September 25, 2007 1:00:28 PM (GMT-0600) America/Chicago Subject: Re: [tc-dev] TC system properties I thought we had a compile jar that represented our internal API for developing transparency. I don't think it is polished and or stable enough to call it a public API but over time we might evolve it to that. Then we also have an API for config module developers. That also is probably not polished enough yet but we have little choice but to allow it to be public with the warning that it can change. Both of those are client side/external facing. System properties feels like just an internal service to me but I'm open to other interpretations. On Sep 25, 2007, at 10:49 AM, Alex Miller wrote: > What's the other concept (besides config modules)? What do you > think are the potential API audiences? > > > ----- Original Message ----- > From: "Steven Harris" <[EMAIL PROTECTED]> > To: [email protected] > Sent: Tuesday, September 25, 2007 12:25:00 PM (GMT-0600) America/ > Chicago > Subject: Re: [tc-dev] TC system properties > > We should be careful about combining those concepts. Don't want to > end up with a super API of a bunch > of random gunk. > > On Sep 25, 2007, at 9:55 AM, Juris Galang wrote: > >>> I think (please correct me Juris) that the "api" consists of common- >>> api, dso-l1-api, and thirdparty-api and this api is that subset of >>> stuff exposed to config module implementors. >> >> Correct. Initially, the idea was that the API would be aimed at >> config module developers, but there's no reason why it shouldn't be >> useful for other types of projects. >> >> On Sep 25, 2007, at 8:10 AM, Alex Miller wrote: >> >>> I suspect the answer is yes to both but it depends what you mean by >>> internal and external? >>> >>> common-api will be exposed to implementors of config modules. Is >>> that an internal or external usage? >>> >>> I think (please correct me Juris) that the "api" consists of common- >>> api, dso-l1-api, and thirdparty-api and this api is that subset of >>> stuff exposed to config module implementors. >>> >>> >>> ----- Original Message ----- >>> From: "Steven Harris" <[EMAIL PROTECTED]> >>> To: [email protected] >>> Sent: Tuesday, September 25, 2007 10:06:06 AM (GMT-0600) America/ >>> Chicago >>> Subject: Re: [tc-dev] TC system properties >>> >>> Is common-API for internal API's or external Api's? >>> >>> On Sep 25, 2007, at 8:01 AM, Alex Miller wrote: >>> >>>> Seems like a good idea, but I would think common-api would be >>>> better. >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Geert Bevin" <[EMAIL PROTECTED]> >>>> To: [email protected] >>>> Sent: Tuesday, September 25, 2007 9:46:52 AM (GMT-0600) America/ >>>> Chicago >>>> 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 >>>> >>>> -- >>>> Geert Bevin >>>> Terracotta - http://www.terracotta.org >>>> Uwyn "Use what you need" - http://uwyn.com >>>> RIFE Java application framework - http://rifers.org >>>> Music and words - http://gbevin.com >>>> >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
