[evla-sw-discuss] code organization

[Kevin Ryan]

I think we will find that if we do our homework in naming paths by  
their (content's) function the rest will sort itself out so that we  
won't have things mixed together that should not be.

In the 'gui' directories of widar, all of the sources are Java, but  
in the low-level CMIB real-time software area they are 'C' files.   
They naturally sorted themselves because of the way their paths were  
named after what they do.  The deployed server-side directories have  
a 'config' directory that contains XML files, but if we implemented  
configuration files using something other than XML, the path name  
would still remain the same.  If instead we called it 'xml' then we  
would have configuration files mixed in with XML files for other  
purposes.  And, if we decided to use something other than XML for  
configurations, our path becomes broken.

On the other hand, some different-language files make sense to be in  
the same directory like JNI C and Java files; or, if I'm searching  
for a particular CGI implementation, I should not have to know if it  
was written in C or perl or any of the many other possible ways to  
implement CGI.  I should just be able to go to the CGI directory and  
find it by its function.  I will discover what language it was  
written in by its extension.

Structure this with the best interests in mind for sharing,  
development and deployment as a system - not what tools were used to  
implement it.  Someone outside our group should not have to stumble  
around the paths based on how Maven or CVS or Subversion works (make  
those things work with _our_ hierarchy not theirs); nor should they  
have to know what scripting-language-du-Jour was used to implement a  
specific function.  Implementation can change and when it does, we  
don't want our hierarchy to break.

Kev

On Oct 25, 2006, at 3:34 PM, Bryan Butler wrote:

>
> i agree with brian here.  for the webapps they also need the  
> related assembly
> and config stuff, and it's nice to have it separated out.
>
> sometimes it's nice to have everything all in one directory, but as  
> things get
> more complicated, it becomes impossible to find the needle in the  
> haystack, as
> it were.
>
> 	-bryan
>
>
> On 10/25/06 15:31, Brian Truitt wrote:
>> Kevin Ryan wrote:
>>> A person searching the hierarchy for
>>> VlaAntenna should know that it is part of the AMCS of the EVLA of
>>> NRAO but should not have to know the name of the processor that it
>>> might run in or the language that it was written in in order to find
>>> it in our source repository.
>>>
>>> Kevin
>>>
>>
>> In this case, how do we organize projects utilizing multiple  
>> languages?
>> We have C, perl, java, and jsp at least strewn throughout our  
>> projects.
>> (There's a perl script used to compile the online help used in the  
>> PST
>> for example). I have no interest in mixing perl scripts in with my  
>> java
>> packages, or my jsp and html for that matter. Where do they go  
>> then? A
>> concrete alternate suggestion for this scenario would be useful.
>>
>> I certainly find the directory structures verbose and lengthy as  
>> well,
>> so alternatives that handle all our use cases are welcome.
>>
>> Brian
>> _______________________________________________
>> evla-sw-discuss mailing list
>> evla-sw-discuss at listmgr.cv.nrao.edu
>> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss