R. Clayton (rclayton@clayton.cs.monmouth.edu)
(no date)
Does the client have to be built with classes that exactly match the
ones you show or can we make funtion calls that take the same types of
arguments?
The API should look like the one in the project specification, but how you make
it look like that is up to you. You can make a class, or a name space, or even
just a bunch of function prototypes in a .h file.
However for quick prototyping simplicity, we built our client as a series of
C++ RFS function calls rather than an RFS class.
That's fine.
The client and server work and send the data and messages as specified in the
project, just the client core is not a class.
Doesn't matter as long as it presents a similar interface.
Also the RFS::RFS_Status messages are simply integers (not some complex data
structure) we parse locally to determine the meaning.
Doesn't matter as long as they behave apropriately (that is, distinguish
between errors and no errors and perhaps among the different kind of errors).
Since we are finished well ahead of time we can re-code the client into a
class rather than a simple function call test interface if it's important to
the project or if function calls are ok, we can use the time to study for
our other classes.
Given the general state of student-written code, I think it's more imporatant
you go over work with an eye towards improving clarity, correctness, and
robustness rather than worrying about casting it in a particular form.
This archive was generated by hypermail 2.0b3 on Sun May 06 2001 - 20:30:05 EDT