Re: [CompStrm Wiki] attribution

[Bill la F. <laf...@ya...>]

Andy,
   
  There is a fine line between explaining and defending. But I think the explaining is important enough to risk such confusion. I could equally argue that having so many source trees adds to the confusion to a newbie, so it should only be done if it is also well documented--which I don't think it is.
   
  Your point about adding builds and tests is a good one. I'd like this project to be easy for someone to adopt. Regression tests are a personal weakness of mine. I do like to develop things in a way that they can be tested, but I don't leave a trail of test code behind me--the bread crumbs are too sparse for others to follow.
   
  As for NetBeans builds, I'm a bit unhappy with what I've got. Every time I do a run in the NB environment, it recompiles over a dozen modules. But its not something I have put any effort into. And obviously it should be worked on. I do like your idea of having a common build under svn. Please say more.
   
  As for RMI, it looks like a quick way to go. I'm rusty at it, and it is really inappropriate as it does too much that isn't needed while not doing some important things well. We don't need object serialization--everything's a string. And distributed garbage collection is a lot of baggage for what we need. But it should be easy to do and I think there may even be a community of folk who know how to write RMI clients. But I'd like to keep the RMI code and clients in separate source trees and limit how much code it contaminates. Ultimately a select-based server will give us much better speed and performance, but right now getting something working and usable is more the point. Lets talk more about this.
   
  As for not being familiar with rolonics, I must say it took me years. But the joke is just how easy and appropriate it is. Reminds me of the shift over to oo. I had a bit of a hard time with that, too. But there was a lot more literature to help. Between the lack of reading material, no good programming examples, lack of community and overall the intimidation factors of terminology and its utmost simplicity, its a big speed bump. And there's still so many simple and easy things that need to be worked out. All I can say is relax and let it flow. It is a really very effective way to approach things, but its so natural that you can't help but try too hard. There is really hardly anything to it. And the words just get in the way.
   
  One thing that might help is Ark vs DArk. The Ark is largely without behavior, just gets and puts. Its all dressed up in a nice API, but there's no validation. DArk addresses partness/descriptors/behavior. Any paramaterizable behavior goes in DArk, leaving Ark with fixed (if sometimes complex) logic. And once you go beyond Ark and DArk, the rest is just architecture, and perhaps not always the best of architecture.
   
  Bill

Andy Glick <and...@ac...> wrote:
  Bill,

I haven't done much RMI work, but I have done some distributed server programming. I'm willing to have you vet anything that I can put together, but I imagine that it may take me some time to come up to speed with the code that you are currently writing. I am not a rolonic initiate yet, I'm still attempting to sort out the principles. 

I wanted to start a discussion about the SVN repository directory structure and the build/release infrastructure, but I am hesitant to do that lest you go off and rearrange everything again before we can conclude a conversation. In one of your recent posts to me you seemed to be defending your original directory structure which contained 2 top level source trees, ark and framework. I didn't have a problem with that structure, but you have since reordered the directory structure and pushed them down a level, and now have a set of top level trees under trunk. Again, that is OK, and I'm not trying to criticize, it is simply that you never explained your actual reasons for creating or demoting the top level artifacts, and I still am not clear on your thinking. 

What I believe that I have understood is that you are:

1) using the Netbeans system's build infrastructure, which you have not committed to SVN 

2) you partitioned the current SVN repository into a set of source trees, {ark, directportal, framework, textclient}  because each subtree produces a single jar artifact.

Given that your stated goal is to interest more open source developers to take an interest in and to lend a hand with AgileWiki, I have some concerns about the project's current lack of build and testing infrastructure, and some suggestions for improving each. I'd be happy to discuss them, either now or at a later date.

Thanks,

Andy

  

				
---------------------------------
 Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time.