Menu
▾
▴
p2pim-devel
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(3) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ryan D. <rdi...@wo...> - 2003-04-19 02:22:58
|
I guess it's time to get back to developing on this project... I spent a little time tonight cleaning up Client.java. I pulled the creation of the about screen and the licensing screen out and put them in their own respective classes. I think now I'm going to start implementing multiple groups. I like the idea of invitations to groups. It would take one user to start a group, then they can invite others to the group. Also, the control module should keep a list of all groups, so users can view what groups available. Private groups? We could require a password to gain entrance? Any thoughts? -Ryan |
|
From: James H. <hol...@ke...> - 2002-12-07 01:54:31
|
I just released 0.6. It still has the issue where profiles can't be changed while logged in. It's going to take more extensive changes than I thought. For 0.7 I want to do multiple groups and an "advanced" option. I've already made changes to the network class so the multicast IP isn't hard coded in it. Control also kills the networking on logout and restarts it on login. I'll make the multicast IP part of the preferences. I'll force myself to get that done this weekend. |
|
From: James H. <hol...@ke...> - 2002-11-04 18:44:22
|
I've added the im.prefs.Preferences class to CVS. To get at the object for the main preferences, call control.getMainPrefs(). This will return a Preferences object. Of course this object is useless if it doesn't have the get/set methods you need, so add them as neccesary. I also changed the name of the preferences file, so it doesn't clobber the file being created by the Client class. We can change the name back once the Client class has switched to using Preferences. When you add new get/set methods to the Preferences, make note of whether you save or not. I made saving preferences a seperate public method. The idea is that we may at some time need to make a large number of changes to the preferences in a short amount of time. Saving after each change would cause massive slow down. So, when you add a get/set method you have to make note of whether you save or not, so we can tell from the docs what changes we have to manually save after and what ones we don't. A forced save on program exit would be a good idea too. |
|
From: <QUA...@ao...> - 2002-11-02 00:28:14
|
I'd go with the get/set methods for properties. True, it's little more work at the start, but once the intital class is written, it will be a trivial task to add a new preference. This design is also less susceptable to race conditions, if at some point down the road, multiple threads are accessing preferences. I'll add this to the TODO list, which should be added to the P2PIM website in the next couple of days. -Ryan |
|
From: James H. <hol...@ke...> - 2002-11-02 00:10:43
|
I think a seperate class is needed to handle preferences. There are two good ways that I see to do it. One, the Preferences can be accesible through a static Properties object. Two, use get/set methods. The first method would be easier. We could put just about anything in it and serialize the object to a file. The disadvantages would be the usual ones associated with static objects. With the second method we would have to make get/set methods for each property we want to store. I prefer the design of the second one, but the first is easier (and I think lazier). |
|
From: James H. <hol...@ke...> - 2002-10-18 23:08:40
|
Forget the ID number. Control can give the GUI a File object when it begins a transfer. I'm thinking of queueing ID numbers because the user might want to send multiple files at once. To do this the program has to keep track of what files it's offering. We could send File objects back and forth, but it would be more efficient, and probably less dangerous, to use an ID to identify files. An ID for the group is ok right now. After thinking about it I realized that using different group addresses and ports doesn't increase security or reduce bandwidth usage. It would decrease the work that the client has to do, but I don't think we're going to be saturating the CPU any time soon. The other options won't require a protocol change either, so they can be easily implemented later. I think a user profile will just be a string object in the user object. It can be arbitrary data, as far as I'm concerned. The UI can create it and interpret it however it wants. |
|
From: <QUA...@ao...> - 2002-10-18 04:13:55
|
The only project in the UI module I would like to complete before we reach the 1.0 milestone is a refactoring/reorganization of what's already there. Client.java is getting becoming cluttered with methods that don't necessarily belong in the main UI class. When you look at the UI module's code, it is clear it was written rather sloppily - I'd like to clean it up, and organize it better. File Transfers- I'm not sure I totally understood your explanation of queuing a file to be transferred. I'm confused on the transfer of the file ID number, why do both the Control and UI modules need this? As far as the actual transfer, we will need to design a segmentation protocol I'm sure - Sending a File object won't cut it. The sending client should be able to read x bytes from an output stream, send x bytes over the network connection, and the receiving client should be able to write x bytes to an input stream. The initial packet sent should contain the file length in bytes. Multiple Groups- Doing multiple groups similarly to the way we do the single now, and just adding another id number, would probably require less change to the existing code. This could still be invitational... we could even allow the group creator to define this id number - or word - just limit it to a certain length. User Profiles- These could be very useful and convenient... what kind of information is contained in the profile? Where is this information stored? How are profiles made available to other users on the network? -Ryan |
|
From: James H. <hol...@ke...> - 2002-10-17 02:46:04
|
With one real release done it's time to figure out what to do next. These are the things that I want to get done before calling it 1.0. Protocol Security- This should obviously be an ongoing project, but before we go 1.0 I want to go through and see if there's any glaring security problems in the protocol itself. There was already the problem with the FAKE command. I want to catch anything else like this as soon as possible. File Transfers- I still have no idea how to do this easily, unless transferring a File object does actually transfer the file. What I think we can do now is set up how to start the transfer. The way I thought of it before was that the UI can call the sendFile method in Control. Control would add the file to a list, and send a send request to the other client. It would return a number to the UI that it keeps track of. When the other client accepts the transfer, they send back that number. That number could be used to identify which file it wants for both the UI and Control. The question is how to do the actual transfer. Multiple groups- There's lots of ways to do groups. We can give each group a different group IP, and a person would enter the IP to join it. It could be invitational, where a person in the group sends an invitation that includes the information the person needs, whether it's an IP or port number. We could broadcast group messages like we do now and add a second header that identifies a group. Control could filter out group messages that the Client shouldn't care about. What other options are there? Advanced options- I have a few ideas for "advanced options". First, the user need to be able to specify the multicast IP used. Right now the first private IP is hard coded. Without any filtering on users, the list could get large pretty quickly. Port options would be handy too, just in case. Handling of username conflicts and users who don't disconnect gracefully- I think that each user should have an identifier besides the username. We can generate a random number the first time the program is run, and then on subsequent logins send that number. This way other clients could tell whether or not the person trying to reuse a name is the person who had the name before. If/When we add security this could easily be switched to a public key. Of course it would be very easy to fake your identity with this system, but if we continue with the assumption that administration is handled outside the program that's no big deal. User profiles- I could implement this using code that I had put it but never finished. I was planning on having clients let each other know when they seemed to be missing people from the list. This would improve the reliability of program. Also, on login, a user could put himself along with his profile on the "missing" list. This way they can reliably transfer what could be a large amount of information, instead of tacking it onto HELO; and hoping none of it gets lost. I think the username conflict issue is the most important. I want to get that done right away. User profiles will probably require a protocol change too so i'll get that done at the same time. Any comments? |
