/** This the (albiet primitive) bug tracking system for DODS */


*3*(****DONE ***) Fix SDArray types (SDGrid, maybe more) to use the ServerArrayMethods 


		       
			       	       
*4*    ****DONE**** DGrid.checkSemantics() does not check for map vector lengths vs size of
        Grid array. (Duh!)10/25/99
	    **** OK, I added this check, but when I finished I decided that it could 
	    probably never happen that it would fail this test in the first place,
	    the parser should catch this problem...
	
*5*    DGrid.addVariable() doesn't QC shit. (Duh!)10/25/99
        **** Fixed this so it checks to make sure a DArray is passed in...
	

*6*    DDS.send() needs support for compression and MIME stuff (AT LEAST!)  10/25/99 				
		*** MIME Done!*** 12/10/99
		*** Copression Done! *** 12/14/99
		*** Both of these pieces moved into the servlet code...
		


*8*(****DONE ***) CEEvaluator: Fix calls to DataInputStream.readLine 10/25/99

	 
*11*   **** DONE **** Have jgal check the bounds handling for projection information in 
        DArrayDimension and the getDArrayDimension function in DArray 10/26/99

        *** I did it and it seems to work in testing....
	
			 		 
			 	 
*13*(****DONE ***) Eliminate setStart, setStride, and setStop methods from DArrayDimension, SDArray, 
        and SDGrid if possible. 10/26/99
        *** Started: setStart setStride and setStop commented out from all of the above.
        *** Finished. Comments removed. Code Checked in and compiled. 11/2/99


*14*   (****DONE****)Add the serialize() method to ServerMethods (hmmm fun) 10/26/99
       *** Stubbed into everything. 10/28/99
       *** Status:
                    SDBoolean:     Done 11/3/99
                    SDByte:        Done 11/3/99
                    SDFloat32:     Done 11/3/99
                    SDFloat64:     Done 11/3/99
                    SDInt16:       Done 11/3/99
                    SDUInt16:      Done 11/3/99
                    SDInt32:       Done 11/3/99
                    SDUInt32:      Done 11/3/99
                    SDURL:         Done 11/3/99
                    SDString:      Done 11/3/99
                    SDArray:       Done 11/3/99 (see 24)
                    SDList:        Done 11/3/99 (see 24)
		            SDGrid:        Done 11/4/99 (see 27)
			        SDSequence:    Done 11/4/99 (see 28)
                    SDStructure:   Done 11/3/99
	

*15*   **** DONE **** IF the constraint expression is empty nothing gets sent, and that's not right. 
       (ExprParser problem) 10/28/99



*16*(****DONE ***) Debug problem with the selection part of the parser (ExprParser.rel_op()) 10/28/99
        **** Found problem. The current grammer for rel_op produces java code that is broken. 
	    I sent mail to jgal with details. 10/29/99
    	**** FIxed IT! 10/29/99

*17*(****DONE ***) CEEvaluator._cv Clause vector is not initialized after parseing the constraint expression. 
        It should be, even if there was no selection! 10/28/99
	    **** Fixed. Problem with CEEvaluator() Ctor.


*18*(****DONE ***) How deep should CEEval.markAll() go?? Should it tweak start, stride, and stop 
        for Arrays and Grids? 10/29/99
        **** Changed markAll() to go "deep" and modify the array projection stuff.

*19*(**** DONE ****) The way we handle Clauses is flawed. DreferenceClause and FunctionClause both
        have evalBoolean() methods. RelOpClause does not. By what method do we intend to eval Clauses
	    at runtime????  The subtext to this is that I need to write CEEval.evalClauses()... 10/29/99
        **** Fixed - retrograde version of Clause removed from dods.dap.Server. Correct version installed.


*20*(****DONE ***) In serialize() I check to see if the current variable has been read. 
        if not I read it. then I evaluate all of the clauses against it to see if I 
	    should "externalize" it (????) then externalize it...
        What does it mean to evaluate clauses??
        Where do the loperand and roperand get filled (for RelOpClause) Why would these 
	    change from one var to the next duriong serialize?
        **** Implemented as described, evalClauses() calls evalBoolean() of each Clause 
	    in the CEEval Clause vector and returns true if NONE of the Clauses evaluate to 
	    false. The loperands get filled (if they haven't been) in evalBoolean().
	

*21*(****DONE ***) What I see is that there seems to be a syncronization problem with 
        reading variables during the evaluation of Clauses. How do we handle reading 
	    stuff that appears in the Clauses but is not the "next thing to read" from the 
	    DDS?? Do we assume that the read() methods are smart enough to cope? What about 
	    variables with the same name in the DDS? Does this affect things? How does a 
	    particular member of the DDS know from what to read?
        **** Answer Read had better be smart enough to cope with this situation. In
	    reality, (22) is more likely the situation.


*22*(****DONE ***) Since evaluating Clauses causes all of the pertinent data to be read 
        anyway, why do we need to eval all of the Clauses each time we serialize another 
	    member of the DDS?? It seems like we could cache the combined result (T/F) of 
	    evalClauses and just check it. OR (and this gets at another question that is 
	    nagging me) is it possible values of the loperands in the CEEvaluator Clause vector 
	    are supposed to change during the send() process (It was certainly my understanding 
	    that they didn't change once read, but it bothers me that they can't)...
	    
        **** The answer to this is that Sequences are really the only situation where the 
	    evaluation of Clauses means anything anyway. If you were to build a Clause that 
	    references a simple variable at the highest level in the DDS then if the Clause evals
	    to False then no data gets sent. In a Sequence, the DDS contains the description of
	    one row, not all the rows. As each row gets read the variables in the DDS 
	    representation of the row get overwritten. Thus re-evaluating the Clauses for each 
	    row in a Sequence makes sense and will produce the desired (filtered) results.
	    **** It will be important to reset the isRead() flag for each variable in a Sequence
	    prior to reading the next row.
	

*23*(**** DONE *****) Fix bad syntax on Revision field in comments. 11/2/99




*24*(**** DONE *****) DVector contains the implementation of deserialize() and externalize() for both DList 
        and DArray. The implementation for SDList.serialize() can just use the implementation  
	    of externalize() in DVector, as the entire list goes if any of it goes (ie it does not 
	    implement the ServerArrayMethods aka ArrayProjection interface). However, this breaks 
	    for SDArray as the more complicated projection information requires control of the 
	    "externalization" of the array in the child class (SDArray).
        This may require changes to DVector to repair. 11/2/99
	
        **** Actually in SDArray serialize works the same way as in SDList. The part of SDArray
	    that actually handles the "projection" stuff is the read() method. SDArray.read() uses
	    the projection information to get only the stuff from the data archive that is indicated
	    in the constrained DDS. This information is placed in the SDArray's vector of DArrayDimension
	    objects (each one of which has storage for the prjection information for that dimension
	    of the array) by the ExprParser. Thus, since read() is a method of SDArray it has access
	    to SDArray's stuff. The idea is that when the externalize() method (of DVector) gets called,
	    the only stuff in the DVector (parent class and underlying storage of SDArray) is the stuff
	    indicated by the projection information. i.e. it all gets sent.
	    *!*!*!*!*! This may require some monkeying with DArray and SDArray to mak it work...


*25*    (****DONE****) I remain unconvinced that the solution for SDArray in (24) is right for SDArrays 
        of complextypes... We will need a test DDS with an Array of Structures or some such to check
	    it. 11/3/99
	     **** I got over it... ndp
	
*26*    DArray.addVariable() does not check the passed parameter v for type if the parameter part
        indicates that v is a map vector. 11/3/99
	    **** Fixed see #4


*27*    (**** DONE *****) Does (24) hold for SDGrid? i.e. does the application of the projection information  
        happen in SDGrid.read()? If that's true, then can we just call DGrid.externalize() since the contents
	    of the array and the map vectors contain ONLY data which is going to be sent? If that's not 
	    true, then what do we do???  
	    
	    **** In fact it is supposed to work the same as SDArray. The projection information is used 
	    by the read() method to get only the requested part of the grid. Thus serialize(), after 
	    insuring that the data has been read (and checking clauses) can just call DGrid,
	    externalize() to send all of the data contained in the object.


*28*    (****DONE****) When I went to implement SDSequence.serialize() I realized that it was going 
        to be identical to all of others. The functionality to read each line (over and over  
	    until it's done) actually is in CEEvaluator.send(). At least that's how it looks right now...
	    

*29* (****Done ***) DDSParser.NonListDecl() doesn't contain support for DList
     or DArray. OOPS! 11/4/99 *** Corollary: NonListDecl() gets called for Lists
     and Arrays. OOPS! *** And Structures, and Grids This needs fixed ASAP!!!!!!

     I claim this is done. 11/15/99 jhrg


*30* (****DONE****)In SDArray.read() (and SDList.read() and SDGrid.read()) there are
     serious issues wrt to placing data in to the underlying data
     representation (in memory). In particular the DVector that is the parent
     class of DArray and DList stores data in a PrimitiveVector. The methods
     of PrimitiveVector that are available do NOT allow data to be assigned
     at run time. You must determine exactly WHAT kind of PrimitiveVector (ie
     BasTypePrimitiveVector, BytePrimitiveVector, etc.) you have and then put
     data into it using the correct method via casting the PrimitiveVector to
     the correct type. I am unclear if this represents a problem with the
     architecture, my understanding of what is available in the read()
     methods, or if Servers can make assumptions (ie I know what I am serving
     so I should know what data type a particular variable is going to
     be....) *** UGH! You can skirt around this by checking all possible
     cases of instanceof on the PrimitiveVector in the Array... Ick...
     
     **** The situation exists because the test classes that we are writing need 
     to respond to all possible DDS's
     
	    
*31* (****DONE****) I Can't seem to pass array projection information to the parser and get
     any kind of result. Need to know the constraint expression syntax for
     that...
     **** Fixed 11/16/99 jhrg
     
     

*32*    ****DONE **** Implement read() for test types:
        *** Status:
                    SDBoolean:     Done 
                    SDByte:        Done
                    SDFloat32:     Done
                    SDFloat64:     Done
                    SDInt16:       Done
                    SDUInt16:      Done
                    SDInt32:       Done
                    SDUInt32:      Done
                    SDURL:         Done
                    SDString:      Done
                    SDArray:       Done 11/8/99 (see 30)
                    SDList:        Done 11/8/99 (Assuming you can arbitrarily set the length of the List)
		            SDGrid:        Done 11/15/99
			        SDSequence:    Done 11/16/99
                    SDStructure:   Done 11/16/99


*33* **** DONE ****Bug: Can't specify the componets of a grid in a constraint expression. 
     For example: In a grid with internal array g and map vectors, i,j, and 
     k a constraint expression of "g" will cause a NoSuchVariableException 
     to be thrown.
     **** James fixed this (YEAH!!)
     

	
*34*  ****DONE**** Read() methods in test classes need to be made to look more like the setProject() methods.
     ie read() should check projection flags!
   ->*** Is this really true? What happens when you need to read a variable that isn't projected but
     appears in the selection component of the constraint expression?
     *** True for Dconstructors and fixed already! 12/14/99
	
  
          

*35* **** DONE **** Instrumentation should only print out the variables requested after (and maybe before) they are read.
     This might be something for the testclasses OR something for the Server Abstract types...
   ->*** What about a printVal(sink,boolean) where we use the boolean flag to indicated wether or
     not we want the entire object

    **** Made printVal() only print projected stuff. See #39

     
*36*  **** DONE **** DDS parser pukes on test14. DDS follows: 

            # test problems with named dimensions.

            dataset {
                int32 i;
                float64 f[ longitude 10 ];
            } data5;
	    
	James??
	**** This DDS is supposed to choke the Parser.
	


*38* ****** DONE **** Need to fix printDecl() to work with constrained server types (preserving client functionality)

*39* ****** DONE **** Need to fix printVal() in server types (utilize projection information)


*40* **** DONE **** Need to make a smarter read() for the children of DConstructor

    *** Reads only the members of the DConstructor that are marked projected....
    

*41* ****DONE**** Is there a nasty bug wrt the ReadMe flag in the SDtypes? Does it get set and checked correctly?
     Especially in the serialization of SDSequence???
		*** YES! There was a nasty bug and I squished it!

		
		
*43*	***DONE***	Fix Exception messages so they do NOT contain double quotes
		**** Found problem in DGrid.getVariable().

*44*	***DONE*** Add DDS.getFactory()

*45*	***DONE***	Use 44 in CEEval.parseConstraint() and remove BasetypeFactory from 
		parseConstraint()'s type sig.

*47*	***DONE***	push server implementations from jdods into DODSServelet
		add abstract method getDDS() to DODSServlet that returns a parsed and 
		populated DDS (getDDS to be implmented by DODS human clients)
		
*50 *	***DONE***	in DODSServlet return a DODSERROR obj for:
			doGetDAS()
			doGetINFO()
			doGetHTML()		

*52*	***DONE***	Nathan makes a drawing of new directory structure. James approves and alters
		CVS to reflect it.
		
*54*	***DONE***		What about printing a constrained DDS if there is a 
		constraint expression sent along with the request for the DDS??? Fix in DODSServlet!


*55*	 	***DONE *** Nasty new bug. Lists of Arrays that I send to geturl break something... 
		Is it me or is it geturl?
		*** This problem has 2 parts: 
			(1) Projection flags are not getting set in arrays of BaseTypes 
				(fundamentally a parser problem)
			*2* DONE!  The length of the array is sent twice because of behaviour in the
				C++ client. The C++ client is not consistant, as it only consumes
				2 length variables if the arrays & lists are of simple types. Arrays
				and lists of BaseTypes only get one length value consumed when they arrive
				at a client. BUG! ICK! 
				Do we fix the C++ stuff? Or do we make the java stuff compliant? Don't
				forget that the java code needs to be ammended for both sending and
				recieving these types (server and client code!!)
		**** (2) Is fixed. Java code accomodates funky C++ core *sigh*
		
				
*56*		****DONE**** There is a failure to call the read() methods of members of structures 
		in a list of structures.
		Possibly the same error as 55.1 ?
		
		*** The members of a list do not get their Projection 
			flags set at all (let alone correctly!)
		*** Patching SDList.setProject() to detect BaseTypePrimitiveVectors 
			and to recursively set the proiject flag for the BaseType Template 
			variable causes data to be sent (which it wasn't before) BUT, geturl 
			doesn't like the output (the binary looks good on inspection)...
			
		*** SDArray has the SAME bug!! (Arrays of Structures, etc. could be bad)
		
		*** This bug ALSO affectes arrays and lists of Strings (which implies URLs too)			
			

*57*	****DONE**** The Parser geneterates error message text that contains double quotes. How
		Might we fix that? (For now I detect it in the servlet when I recieve a
		parser exception and I replace all of the  double quotes with single quotes)
		Fix when we fix 42!
		
*58*    ***DONE*** geturl fails (segmentation fault) on test.03 Lots of arrays! What's the problem?
		*** Arrays of strings are broken! It looks like the right stuff is getting sent but 
		geturl is barfing on the transmission. Why? Jake padings with nonzero values??
		**** Same as 55! It's barfing because of something todo with the length headers, etc...
		
		*** Same bug as 55.2. Java code accomodates funky C++ core *sigh*


*59* 		****DONE****When serializing Int16 and UInt16 I've got to send each 16bit value as a 32 bit value
		for geturl to understand it. Is that correct? 
		****YES


*63*      Parser (ExprParser) does not allow use to select members of a 
		Grid by simple name...	
		Fixed 1/28/2000 jhrg					
				
67		When making a selection in the constraint expression if the variable used in the selection
		is just named (say: http://balhblah/test01.dods?sst&year>1986) then the parser throughs an
		error. The parser accepts the constraint expression if the selection variable(s) are fully
		qualifed (ie  http://balhblah/test01.dods?sst&project.cruise.year>1986)
		Fixed 2/10/2000 jhrg

68		Given 67, if the parser accepts this fully qualified variable name, then the Clause objects
		dod not get properly populated (the loperand is empty!)
		Fixed 2/11/2000 jhrg		
