UrlyBird DBMain puzzles

[Bernard Russell]

I have the UrlyBird 1.3.2 assignment. The DbMain interface that I have to implement is quite confusing and I would appreciate some help/opinions on it.

1) There is a create method listed - but there is no way that the client I am developing should ever need (or be able) to create a room availability. Should I provide an implementation for the interface method, or would it be sufficient to provide a blank method and then document it as such?
2) The interface refers to "record numbers". Is this just the number assigned to each record, in order of reading from the file? Will those record numbers ever change?
3) When someone "books" a room, should it be deleted from the file, or just a customer ID entered for it? And if the latter, should other clients ever even see that record at all (in other words, should clients only ever see available rooms)?
4) There are lock and unlock methods, but I am puzzled by them. What happens if a lock is obtained by a client, who then logs off abruptly or otherwise just stalls forever and ever. Should the lock be released after some time period?

Sorry for all the questions, but this aspect of the specification has been particularly difficult for me to understand. Thanks!

[Herman Schelti]

hi Bernard,

I did UrlyBird last year (can't remember which version)

1. yes, you have to provide an implementation. GUI and serverside are two different things. Sun will probably run a script to test your "create" method.

2. Yes, it's just the number assigned but don't know if it changes. I assumed it didn't.

3. If your specs don't say it should be deleted, then don't make it. Just make what they ask. Same goes for hiding booked rooms: does it say so in your specs? If not: don'make it.

4. If you lock client-side that's possible. I choose to lock server-side only. Server does not go on holiday without unlocking...

Herman

[Bernard Russell]

Herman - thanks for the reply and for taking the time to answer my questions.

I am developing a middle-tier server to the client that looks a little more logical. It allows clients to book a room, or search for vacancies, but does not allow access to locking or deleting them. That solves many of the problems with the odd interface.

I am slowly getting to grips with the exercise, but it's tricky. Thanks again for your comments!