Last Concerns

[Matt DeLacey]

I'm VERY close to submission time (for me that means, hopefully in less than two weeks). Everything works, the code is all cleaned up. I've got a lot of the documentation done, I've tested it a bunch, and all. I have a few last concerns that maybe some people can either put to rest or convince me that I ought to just go ahead and "fix" them:
1.) I don't have a policy file. It works fine without it. Is this a problem?
2.) This goes along with #1; I don't do any dynamic loading of classes. I just provide the server interface and the stub class in the dir with the client stuff. This only makes sense to me. The only reason I can see for doing dynamic class loading is if the server changes then potentially clients are unaffected.
3.) I do lock/unlock on client side and so obviously I don't track clientID.
4.) I don't implement an entire db lock (-1). It's not clear to me that we're supposed to, although I have read somewhere that people who didn't implement this lost 2 points (not sure how they would know that because the results don't appear to have any comments).
Assuming everything else was really, really good how bad do you think the above (all of them) would affect my grade? I would just do all of them if it was clear to me that they needed to be done, but I hear a lot of people saying "Keep it simple. Only do what is asked."
Thanks,
Matt DeLacey

[Adrian Yan]

Matt:
1. I don't have a policy file neither.
2. I don't do dynamic loading
3. I do lock/unlock on server side, but I don't track client ID.
4. I'm gonna implement the locking db requirement. I'm not sure what it supposes to do, but it looks really simple to me.
From previous discussions with, I think you are really close
Best of luck, man!!!
------------------

[Aron J. Skantz]

Hi guys.
I, as well, estimate 1-2 weeks before i can submit my assignment. I'm very nervous about it and are constantly finding reasons to why I should wait just a little longer. Anyway, here is what i did:
1: I use a policyfile, but see no reason to why either way should cause a drop in points if you explain your choice.
2: Dynamic loading is, if you ask me, way beyond the criterias and a single line motivating why not to implement it should be enough in the design document.
3: Hey, must be something in the air I do unlock/lock on the server without tracking clients.
4: I did implement the -1 lock in the simplest of ways, but i thought long and hard about the various solutions. If anyone are interested, ask.
This last week i have actually removed stuff from my code (double clicking in the table to book etc), cleaning it up and simplify it to just do what the criteria states and nothing more. Keeping it simple is everything here I belive. No one can blame you for doing only what you were told to ;)
(Adrian: you are the only person here besides myself that has choosed to implement server side locking without client tracking and i would like to talk to you about how you motivate it and exchange thoughts. So, mail me if you want to talk about it, otherwise, just dont. I really dislike mailing people that do not wish to talk
Good luck!
Regards,
Aron

[Adrian Yan]

Aron, cool. i think I stirred some controversy over this before at egroup.com. Anyway, yea, my decision was simple: I don't want to client to do anything stupid . Another reason, I figured putting booking, locking and all these functionalities on server-side is like using stored procedures on a real RDBMS. I want the server to handle all of the functions, so my client-code can easily redesign, reuse.
I'm also in my final stage, hopefully I can finish this by the end of the month.
I been doing alot of refactoring, I guess. I removed alot of fancy stuff from my program, like instead of creating complex search gui for client, I just ask them to enter a query string like in the instruction.
How about you?
[This message has been edited by Adrian Yan (edited April 03, 2001).]

[Matt DeLacey]

OK, I think I'm going to switch my booking over to the server. I thought it was a bad idea to have it on the client but the directions are very excplicit about the signature of lock and unlock and they are public and the directions also say explicitly that all public methods should be made available to the client. This made me think that lock/unlock were meant to be called from client...although I can see obvious reasons why that would not be a good idea. So if you do that, are you then changing the signature of lock/unlock to private? If not, supposedly you are making lock/unlock available to the client and that's not good...I'm still a little frsutrated about this. I think the directions are very misleading in terms of this part of the project.
With Respect,
Matt DeLacey

[Aron J. Skantz]

Matt,
Actually im think about doing the exact reverse thing. Changing from a book method on the server to the client. The main reason is that I feel that a book method is much to ungeneric to be placed in the Data class. Also, the fear that the client should mess up is not a valid since i write the client myself and know that they will behave.
By moving book(..) to my client the Data class will be in every way reusable and this is probably a strong point to show this to the examinator, but then again, Im only guessing.
Also, I think SUN has left the directions as misleading as they are to force us to motivate our decisions and make us think. And I believe that you don't have to change your current implementation to pass, just motivate and explain and you will be fine.
Adrian has many good reasons to why to keep the booking on the server, and I think either way will do fine.
Regards,
Aron

[Matt DeLacey]

Thanks for your words. Yes, every minute it seems I change my mind about this. I'm really struggling with it. I think I would leave it on the client side, it's working well, but everyone keeps saying, what happens if you have some network error, say, and the client crashes while it has a lock. You have no way to detect that on the server. I've seen people talk about clearing out locks after a certain amount of time, but it seems that could be kind of a mess and it strikes me that there is no time that is appropriate...it's either going to be too short or too long, in any event it's an unsatisfying method to me. However, the fact that the client COULD die with a lock seems to be a terrifying prospect for people. So much so that they seem to imply that that in itself could result in failure. Not sure if that is so, but it has me scared.
With Respect,
Matt DeLacey

[Matt DeLacey]

Regarding the policy file. I have always thought this is unnecessary. Mine works well without such so why include a policy file. Well, I just thought (or perhaps read somewhere before I understood and now it's creeping back into my subconscious) "What if the person evaluating your project has a policy file on their system (i mean, they WILL) that has been modified so that it has a security policy that is too restrictive to run your project?" I don't know, but I believe the answer is You fail. The evaluator is probably not going to take the time to see that this is the case, they will just get some security error and say, "It doesn't work." So, I'm going to do one. Bare bones, very simple, but I no believe it's a necessary component.
With Respect,
Matt DeLacey