I just thought I'd add another $0.02 and mention that I for one would like to have a better idea of the roles and responsibilities that each one of us will have. Bob Stevens and I are still unsure of how much time each of us will be able to spend working on this project. We would also like to know what the various strengths and weaknesses of each group member are, what it is that they would like to do, etc. I personally think that I will be able to spend, at the very least, a few hours per week on the project. Also, I think I have enough experience with C/C++ to be able to make many contributions to the project. But I should mention that I have little experience with socket programming, so I think it might be best for me to work on text processing modules.
There are also a number of other issues that should be addressed. Web page development is one of them. We need to address both the style and content of the page. What should we include on the project web page? How should it all be laid out? I'm not as concerened woth the latter question, as I only think that the web page should look at least somewhat professional.
I would like the developers to check the forum for developers, as I would expect important notes to be posted there. In fact, some important information is already there. I would like you to read it if you haven't already done so.
Thanks, and good luck.
J.K.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am starting to think through the design for SpamProxy. Bob Stevens and I have chatted about the possibility of me taking a leading role in its development. I want to make sure this program is very well thought out and securely implemented. There are two design patterns from "Design Patterns" by Gamma, et. all., that apply to this project, "Proxie" and "Adapter."
There is a good chunk of work that would need to be done before code is cut. A little UML might be helpful, but I think an Extreme Programming process will do. That means we need to have some solid use cases/stories for the user and the remote system.
A few key questions:
1. How smart must the proxie be when dealing with POP (and later IMAP) traffic?
2. How do we know when a message has been downloaded entirely, so it can run through SpamAssassin for markup.
3. Error handling, what happens if the connection is dropped or if SpamAssassin is not available or some other fault condition occurs. How can SpamProxie handle problems gracefully?
4. Test cases! We will need test cases throughout the development, full regression testing to help ensure that some problems don't sneek up on us later.
- Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good to hear from you. Anyway, I'd have to agree that this project should be well-thought-out and much work will need to be done before even a single line of code is written. And of course it must be secure. And I think the best way to make sure it's secure is to think of all possible ways in which it can be insecure. So there's going to be much planning ahead before any code is written.
Ok, as for how to implement it. I haven't really looked into design patterns yet, as I thought that a simple objected oriented approach will do. But I'll look into patterns if you think it's a good idea. I believe I've already mentioned that I wanted to do it in C++ because of its support for object orientation. If it's going to be cross-platform, then there'll be plenty of use of inheritance.
We definitely need to come up with use cases, preferably as many as possible, however we choose to do it. The "Extreme Programming" approach might be good, we just need to research it and find out if we agree that it's best. Now regarding the questions:
1. I'm afraid I'm not sure what you mean when you ask how smart the proxy must be when dealing with POP and IMAP traffic. I think out daemon must be able to deal with al kinds of it, so should be prepared for anything. That's what I think anyway.
2. I think this question can be answered by checking the RFCs for the protocols we're implementing. It is probably protocol-related.
3. For error handling, we just come up with all cases of where things can go wrong. A defensive programming approach would be good. In the code, just keep checking to see if anything might have gone wrong. Any time you try to connect to a remote system, do nothing until you know you're connected, and give a timeout error if you can't connect. As another example, if the connection is dropped, it's something that'll have to be detected, then it'll just go on with processing the messages it downloaded completely, and work with them (this is for POP connections.)
4. We most certainly need test cases. Test cases should be traced back to requirements. We test to see if each requirement is met. Regression testing is good but I hope we can make the modules as independent (or orthogonal, if you prefer that term) as possible.
So let's see if we can get some work done. We'll have to think about these cases, and then put them together in some design docs.
Good luck.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello.
I just thought I'd add another $0.02 and mention that I for one would like to have a better idea of the roles and responsibilities that each one of us will have. Bob Stevens and I are still unsure of how much time each of us will be able to spend working on this project. We would also like to know what the various strengths and weaknesses of each group member are, what it is that they would like to do, etc. I personally think that I will be able to spend, at the very least, a few hours per week on the project. Also, I think I have enough experience with C/C++ to be able to make many contributions to the project. But I should mention that I have little experience with socket programming, so I think it might be best for me to work on text processing modules.
There are also a number of other issues that should be addressed. Web page development is one of them. We need to address both the style and content of the page. What should we include on the project web page? How should it all be laid out? I'm not as concerened woth the latter question, as I only think that the web page should look at least somewhat professional.
I would like the developers to check the forum for developers, as I would expect important notes to be posted there. In fact, some important information is already there. I would like you to read it if you haven't already done so.
Thanks, and good luck.
J.K.
I am starting to think through the design for SpamProxy. Bob Stevens and I have chatted about the possibility of me taking a leading role in its development. I want to make sure this program is very well thought out and securely implemented. There are two design patterns from "Design Patterns" by Gamma, et. all., that apply to this project, "Proxie" and "Adapter."
There is a good chunk of work that would need to be done before code is cut. A little UML might be helpful, but I think an Extreme Programming process will do. That means we need to have some solid use cases/stories for the user and the remote system.
A few key questions:
1. How smart must the proxie be when dealing with POP (and later IMAP) traffic?
2. How do we know when a message has been downloaded entirely, so it can run through SpamAssassin for markup.
3. Error handling, what happens if the connection is dropped or if SpamAssassin is not available or some other fault condition occurs. How can SpamProxie handle problems gracefully?
4. Test cases! We will need test cases throughout the development, full regression testing to help ensure that some problems don't sneek up on us later.
- Frank
Good to hear from you. Anyway, I'd have to agree that this project should be well-thought-out and much work will need to be done before even a single line of code is written. And of course it must be secure. And I think the best way to make sure it's secure is to think of all possible ways in which it can be insecure. So there's going to be much planning ahead before any code is written.
Ok, as for how to implement it. I haven't really looked into design patterns yet, as I thought that a simple objected oriented approach will do. But I'll look into patterns if you think it's a good idea. I believe I've already mentioned that I wanted to do it in C++ because of its support for object orientation. If it's going to be cross-platform, then there'll be plenty of use of inheritance.
We definitely need to come up with use cases, preferably as many as possible, however we choose to do it. The "Extreme Programming" approach might be good, we just need to research it and find out if we agree that it's best. Now regarding the questions:
1. I'm afraid I'm not sure what you mean when you ask how smart the proxy must be when dealing with POP and IMAP traffic. I think out daemon must be able to deal with al kinds of it, so should be prepared for anything. That's what I think anyway.
2. I think this question can be answered by checking the RFCs for the protocols we're implementing. It is probably protocol-related.
3. For error handling, we just come up with all cases of where things can go wrong. A defensive programming approach would be good. In the code, just keep checking to see if anything might have gone wrong. Any time you try to connect to a remote system, do nothing until you know you're connected, and give a timeout error if you can't connect. As another example, if the connection is dropped, it's something that'll have to be detected, then it'll just go on with processing the messages it downloaded completely, and work with them (this is for POP connections.)
4. We most certainly need test cases. Test cases should be traced back to requirements. We test to see if each requirement is met. Regression testing is good but I hope we can make the modules as independent (or orthogonal, if you prefer that term) as possible.
So let's see if we can get some work done. We'll have to think about these cases, and then put them together in some design docs.
Good luck.