marc fleury wrote: >|Changes to come will further absrtact and detach File usage, abstract >|logging or provide >|logging adapters, and provide an api for core system configuraton >|(descriptors and such). > >This I cannot make sense of. I mean the point is weak. > Yes, yes the second 57 words are things that we may need todo and I don't currently have any plans todo anything about them.... except perhaps abstracted File usage, but I don't have a clear picture for how that should be done yet, so I am gonna let that one cook.
>Don't complicate the codebase with nth degree bullshit FOR NO GAIN > >SO DON"T DO ANYTHING THERE, see how people use the embedding, let them ask >for the feature. > I don't believe that anything I have done has complicated things, perhaps made it a bit more sophisticated. Again, I am gonna let things cook for a bit. Perhaps we can get someone to actually embed and give us feed back too. >|MBeans will also be modified to return structured data instead of html >|preformatted strings, >|which could be rendered as plain or html as needed. > >Wow, while that fits in 57 words, it has nothing to do with the stuff above. > I was trying to fill up 57 words... >I think we got a good case of "your first idea is good, your second one >stinks". > And there is good reason todo this, as we can not really expect that an embbeded user will have html capabilities, but will have the capacity to iterator over a set and such. I think it is more like "it takes a bit for folks to get what I am talking about". Sure sometimes I come up with crap, don't we all... >Ok, so you are done, stop working. Let the requirement bite your ass before >you take your keyboard again. Do you hear me? I don't want to see a single >commit. > This is just plain silly. As issue some up I will need to resolve them... thus commiting. I am working on the layout changes for a 3.0 final now... which will eventually need to be commited. >Don't code with your sense of style or your sense of perfection, they both >suck, everyone's sense of style and perfection suck, they just do, that's >just "taste" and it all sucks. > Lets not talk about who's style sucks. There isn't really a point to that a? It just gets me fired up and I would rather avoid that. Being an artist I assert that style is important. Being a virgo I can not help but strive for perfection. Being an engineer I can not avoid either of these from affecting my work. >Code with your sense of necessity (a la hiram) meaning " I really need this >feature, I really do, and here is the SIMPLEST way to do it". The rest MUST >go to /dev/null. > Agreed... for the most part. Most of what I do is structured, in that layers must be put in place to allow for later layers to be placed. Take for example the build system changes that I originally did. I did that so that I could better help fix tx, mdb and jms problems. It was a needed step to avoid wasting time down the line, compiling and sorting out the mess to get jars from a to b with out missing a step and invalidating tests. I could have just skipped right to fixing the code, as that would have been simple, yet it was not the most effective solution. >OK? "le mieux est l'ennemi du bien" (better is the enemy of good) but I >remember making this point to you 6 month ago on buildmagic. Go simplify >buildmagic first, please! > Yes you did make this point. I think something is lost in the translation though... unless your perspective is that better is pointless since good is good enough. I think that might be true if better adds a degree of complication and does not provide substantial gain. If something is "better" then it isn't it already "good"? I will work on the build system soon. I am still hoping you will provide some concreate examples of the complexity you see.... anyone else for that matter. What is simple to me may be complex to you (as well as the opposite yo). --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
