Sounds good. On Mar 30, 2008, at 5:28 AM, Geert Bevin wrote:
> Sure, I totally applaud that and I think we should definitely explore > other directions, it just felt weird in the light of solving the issue > at hand and it felt to me like going into another direction to > circumvent the root problem. > > Maybe we should create a new issue for that in Jira to explore > different buffer implementations for the CVT. Considering the memory > buffer implementation, there are several features that wouldn't be > available anymore, and maybe that's ok ... needs some investigation. > For instance, being able to retrieve statistics on a client that > crashed but that hasn't sent out the buffered data yet or when there's > a network bottleneck, storing all the data locally until the end of > the capture session so that nothing would intervene in the network > usage. I'm sure that different buffer implementations can be useful > wrt. preventing intervention with the actually captured statistics > data. To evaluate them, I think we should work from real life use > cases that can now be done since the system is available to everyone > ... then we can work from there. > > On Sun, Mar 30, 2008 at 1:23 AM, Steven Harris <[EMAIL PROTECTED] > > wrote: >> Every inch of the system gets reviewed and redesigned all the time. >> We >> made some assumptions >> back then, one of them being that we needed a client side cache and I >> was thinking >> about it and trying to decided in my head as to whether I still >> believed it was necessary >> or not. I see it as just a part of the process of iterating on and >> potentially improving the >> system. >> >> Anyway, while the logs are certainly a similar class of problem their >> is always the possibility >> that each has a solution that is best for each issue. Can't hurt to >> explore those avenues independently >> and then seeing if the ideas for each can be applied to the other. >> >> It's not like we have to go off and implement anything right away but >> why not think about these things >> with the assumption that solutions exist. We have solved many an >> impossible problem with that mindset >> in the past. >> >> Cheers, >> Steve >> >> >> >> On Mar 29, 2008, at 4:12 PM, Geert Bevin wrote: >> >>> I don't understand where this is going though, all these issues were >>> discussed at length during the design process. Why are we >>> questioning >>> what we decided back then for a problem that has nothing to do with >>> CVT. The fact that log files have been unavailable for as long as I >>> can remember on clients that don't setup tc-config.xml when they run >>> on the same node, seems much more critical to me than the statistics >>> system not being available. If that problem is solved, the CVT can >>> use >>> exactly the same approach. >>> >>> On Sat, Mar 29, 2008 at 7:07 PM, Geert Bevin <[EMAIL PROTECTED]> >>> wrote: >>>> That entirely depends on how many statistics are being captured, >>>> what >>>> the sample size is and what the emission frequency is. >>>> >>>> >>>> >>>> On Sat, Mar 29, 2008 at 7:03 PM, Steven Harris <[EMAIL PROTECTED] >>>>> wrote: >>>>> That can't be done in memory? How much data are we talking about? >>>>> >>>>> >>>>> >>>>> On Mar 29, 2008, at 4:02 PM, Geert Bevin wrote: >>>>> >>>>>> We need the client side db as a buffer so that the stats >>>>>> capturing and >>>>>> storage can complete immediately and the stats emitter can be >>>>>> batched >>>>>> and done in the background. >>>>>> >>>>>> On Sat, Mar 29, 2008 at 6:58 PM, Steven Harris <[EMAIL PROTECTED] >>>>>>> wrote: >>>>>>> >>>>>>> Are we sure we even need the client side db? How big does this >>>>>>> thing get? >>>>>>> can it be optional? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mar 29, 2008, at 2:08 PM, Taylor Gautier wrote: >>>>>>> >>>>>>> Ahh, right, I was referring to the demos, where we have a unique >>>>>>> directory. >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Geert Bevin" <[EMAIL PROTECTED]> >>>>>>> To: [email protected] >>>>>>> Cc: [email protected], [email protected] >>>>>>> Sent: Saturday, March 29, 2008 1:53:54 PM (GMT-0800) America/ >>>>>>> Los_Angeles >>>>>>> Subject: Re: [tc-dev] need to standardize on the system property >>>>>>> names >>>>>>> >>>>>>> How do we solve it? Maybe something was committed over the past >>>>>>> days >>>>>>> that I missed, but if I correctly remember (can't really check >>>>>>> atm), >>>>>>> we print out a one line warning and don't log on any of the >>>>>>> other >>>>>>> clients on that node. The only difference with what the CVT >>>>>>> buffer >>>>>>> does is that for the CVT, instructions are printed out how to >>>>>>> solve >>>>>>> it. >>>>>>> >>>>>>> In the demos however, we timestamp the log dirs, this is also >>>>>>> what >>>>>>> CVT >>>>>>> does in for the demos. >>>>>>> >>>>>>> On 29 Mar 2008, at 16:41, Taylor Gautier >>>>>>> <[EMAIL PROTECTED]> >>>>>>> wrote: >>>>>>> >>>>>>>> Right, >>>>>>>> >>>>>>>> And in that case, we already solve this problem, so we should >>>>>>>> be >>>>>>>> piggybacking on that solution. >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Geert Bevin" <[EMAIL PROTECTED]> >>>>>>>> To: [email protected] >>>>>>>> Sent: Saturday, March 29, 2008 12:42:52 PM (GMT-0800) America/ >>>>>>>> Los_Angeles >>>>>>>> Subject: Re: [tc-dev] need to standardize on the system >>>>>>>> property >>>>>>>> names >>>>>>>> >>>>>>>> Another thing to factor in is that currently the exact same >>>>>>>> problem >>>>>>>> exists for log files when several clients are launched on the >>>>>>>> same >>>>>>>> node. >>>>>>>> >>>>>>>> On Sat, Mar 29, 2008 at 12:57 PM, Steven Harris >>>>>>>> <[EMAIL PROTECTED]> wrote: >>>>>>>>> I forgot the third option of not starting the db until stats >>>>>>>>> are >>>>>>>>> requested. >>>>>>>>> - Downsides >>>>>>>>> would either leave caches lieing around >>>>>>>>> or would give the error message when stats are started. >>>>>>>>> >>>>>>>>> How big an issue is this based on the fact that stats are for >>>>>>>> testing >>>>>>>>> right now not for >>>>>>>>> production? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mar 29, 2008, at 9:01 AM, Steven Harris wrote: >>>>>>>>> >>>>>>>>>> The way I see it we have two choices: >>>>>>>>>> >>>>>>>>>> either we need something that can be created and then >>>>>>>>>> destroyed >>>>>>>> on >>>>>>>>>> exit aka the deleteOnExit file >>>>>>>>>> -The only objection of heard to this so far is that H2 >>>>>>>>>> doesn't >>>>>>>> support >>>>>>>>>> it. Is their a reason that we can't >>>>>>>>>> make H2 do it? or could we look at other disk cache options? >>>>>>>>>> >>>>>>>>>> or >>>>>>>>>> >>>>>>>>>> We could enforce a unique home directory for each client >>>>>>>>>> where >>>>>>>> it's >>>>>>>>>> data >>>>>>>>>> is stored. >>>>>>>>>> - is their a way to make this not a pain for users? >>>>>>>>>> >>>>>>>>>> Lets go into this assuming the problem can and will be >>>>>>>>>> solved. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mar 29, 2008, at 6:51 AM, Geert Bevin wrote: >>>>>>>>>> >>>>>>>>>>> We've had problems with sticking the db in a temp directory, >>>>>>>> some >>>>>>>>>>> files on Gary's machine that were needed for the db's proper >>>>>>>> working >>>>>>>>>>> were removed on Windows while the application was still >>>>>>>>>>> running. >>>>>>>>>>> That's one of the reasons his first demo failed. >>>>>>>>>>> >>>>>>>>>>> Apart from all that, this really is a product choice, as any >>>>>>>> approach >>>>>>>>>>> is of course possible and I'm just talking from my >>>>>>>>>>> preference. I >>>>>>>>>>> however have to say that I have a strong aversion against >>>>>>>>>>> applications >>>>>>>>>>> that create new files by default on every run in a non >>>>>>>> predictable >>>>>>>>>>> location. >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 27, 2008 at 6:50 PM, Steven Harris >>>>>>> <[EMAIL PROTECTED] >>>>>>>>>>>> wrote: >>>>>>>>>>>> We can't hack H2 to do this? and stick everything in the >>>>>>>> default tmp >>>>>>>>>>>> directory for the os? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mar 27, 2008, at 6:41 PM, Geert Bevin wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Don't think so since the db files are created by H2 and >>>>>>>>>>>>> not >>>>>>>> by us >>>>>>>>>>>>> and >>>>>>>>>>>>> there can be any number of files created for indexes, temp >>>>>>>> queries, >>>>>>>>>>>>> etc etc. >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Mar 27, 2008 at 6:19 PM, Steven Harris >>>>>>> <[EMAIL PROTECTED] >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> I disagree but I'll live with it. BTW, java has a kind of >>>>>>>> file the >>>>>>>>>>>>>> deletes on exit of the JVM doesn't it? Can >>>>>>>>>>>>>> we adjust the db to use that and then use the unique >>>>>>>>>>>>>> names? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mar 27, 2008, at 6:16 PM, Geert Bevin wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> We can, but I prefer not because that would defer any >>>>>>>> problems >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>> creating the db until the time that people actually need >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> capture >>>>>>>>>>>>>>> statistics. Usually when that is the case, you don't >>>>>>>>>>>>>>> want to >>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>> start restarted clients and such to make sure that the >>>>>>>> database >>>>>>>>>>>>>>> can be >>>>>>>>>>>>>>> created. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Mar 27, 2008 at 5:45 PM, Steven Harris >>>>>>> <[EMAIL PROTECTED] >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> Just out of curiosity. When do we create the db. Can we >>>>>>>> wait to >>>>>>>>>>>>>>>> do it >>>>>>>>>>>>>>>> until someone does snapshotting? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mar 27, 2008, at 5:40 PM, Geert Bevin wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Since otherwise at each execution it creates a new >>>>>>>> version of >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> embedded database structure. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, Mar 27, 2008 at 4:58 PM, Taylor Gautier >>>>>>>>>>>>>>>>> <[EMAIL PROTECTED]> wrote: >>>>>>>>>>>>>>>>>> Why would it need to be repeatable? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>>>>>>> From: "Geert Bevin" <[EMAIL PROTECTED]> >>>>>>>>>>>>>>>>>> To: [email protected] >>>>>>>>>>>>>>>>>> Sent: Thursday, March 27, 2008 4:42:21 PM (GMT-0800) >>>>>>>> America/ >>>>>>>>>>>>>>>>>> Los_Angeles >>>>>>>>>>>>>>>>>> Subject: Re: [tc-dev] need to standardize on the >>>>>>>>>>>>>>>>>> system >>>>>>>>>>>>>>>>>> property >>>>>>>>>>>>>>>>>> names >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It's unique, but not repeatable. I think this is ok >>>>>>>>>>>>>>>>>> for >>>>>>>> the >>>>>>>>>>>>>>>>>> demos, >>>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>> not ok for regular applications since it creates a >>>>>>>>>>>>>>>>>> new >>>>>>>>>>>>>>>>>> directory at >>>>>>>>>>>>>>>>>> each execution. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Thu, Mar 27, 2008 at 4:36 PM, Taylor Gautier >>>>>>> <[EMAIL PROTECTED] >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So just to add color to this issue - the samples use >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>> convention: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> <logs>%(user.home)/terracotta/client-logs/pojo/ >>>>>>>> sharededitor/ >>>>>>>>>>>>>>>>>>> %D</logs> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> %D is a unique value. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Geert Bevin wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I wasn't suggesting which property should be used. >>>>>>>>>>>>>>>>>>> My >>>>>>>> point >>>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>> that it >>>>>>>>>>>>>>>>>>> should be the same and I do agree that it would be >>>>>>>> handy to >>>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I agree with that, I was just clarifying why I chose >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> tc.node- >>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>> syntax and not tc.nodeName. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> kind of node discovery in place instead of using >>>>>>>>>>>>>>>>>>> system >>>>>>>>>>>>>>>>>>> properties. >>>>>>>>>>>>>>>>>>> BTW, Maven property been there for over half a year >>>>>>>> and no >>>>>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>>>> reporter this inconsistency. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I don't know what you mean by setup differently, >>>>>>>>>>>>>>>>>>> all I >>>>>>>> see is >>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>>>> I remove <statistics> elements from tc-config those >>>>>>>> dirs are >>>>>>>>>>>>>>>>>>> created in >>>>>>>>>>>>>>>>>>> the current folder, at least when this stuff is run >>>>>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>>>> Maven. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I just tried this and it seems to behave like that >>>>>>>>>>>>>>>>>>> for >>>>>>>> the >>>>>>>>>>>>>>>>>>> client >>>>>>>>>>>>>>>>>>> log >>>>>>>>>>>>>>>>>>> dirs too. So it seems that when the logs and >>>>>>>>>>>>>>>>>>> statistics >>>>>>>>>>>>>>>>>>> elements >>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>> removed, the default values in the xsd aren't being >>>>>>>> applied. >>>>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>>>> needs some further investigation. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Also it is really odd, that even if I specify >>>>>>>>>>>>>>>>>>> different >>>>>>>>>>>>>>>>>>> locations >>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>> those stats folders I still see that huge warning >>>>>>>>>>>>>>>>>>> about >>>>>>>>>>>>>>>>>>> directory is >>>>>>>>>>>>>>>>>>> already being used when launching L1 and L2 from >>>>>>>>>>>>>>>>>>> Maven. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I tried that with the distribution samples and >>>>>>>>>>>>>>>>>>> when I >>>>>>>> change >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> client and server statistics paths, they relocate >>>>>>>> properly to >>>>>>>>>>>>>>>>>>> what I >>>>>>>>>>>>>>>>>>> set them to. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> tc-dev mailing list >>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Geert Bevin >>>>>>>> Terracotta - http://www.terracotta.org >>>>>>>> Uwyn "Use what you need" - http://uwyn.com >>>>>>>> RIFE Java >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 >> > > > > -- > 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
