in the course of introduction to cryptography on coursera professor suggested treating all messages as a long stream XORing them with the key this way we will not need to change the key and will not have the IV problem and the question is if so how can we generate a key that will encrypt the whole traffic using just XOR
WEP used a stream cipher. Stream ciphers are used to take a relatively short key and generate a seemingly endless supply of random data which can be XORed with the plaintext to generate the ciphertext.
That said, it is not really an endless supply of random data (see this Crypto.SE question), so, periodic rekeying would be necessary.
Well, WEP uses RC4 to encrypt, and RC4 can be used to generate a long keystream to encrypt multiple messages. The key would be negotiated when the connection starts; both sides would hand over the negotiated session key to the RC4 algorithm, and RC4 then generates a long keystream that can be used to encryption. In fact, when SSL uses RC4, it does exactly this.
However, when it comes to WEP, there is a significant practical problem that doesn't arise with SSL; message reliability. With SSL, the protocol assumes that the protocol is run over a reliable transport (generally TCP); the transport protocol will ensure that the receiver will get every message the sender sends, and in the correct order (and if it can't ensure that, it raises an error condition that shuts down the connection.
This is important for RC4; it generates a separate part of the keystream for every message. For, if we encrypt two 100 byte messages, bytes 0 through 99 of the keystream will be used to encrypt message 1, and bytes 100 through 199 of the keystream will be used to encrypt message 2. When the receiver gets the encrypted message 1, he can use his copy of the RC4 keystream generator to create bytes 0 through 99 of the keystream, and decrypt message 1.
The problem comes in if the receiver never receives message 1, and instead receives message 2. If he were to ask RC4 for the next 100 bytes of the keystream, he'd get bytes 0 through 99, which won't decrypt message 2 properly at all.
With SSL, this situation never comes up; the underlying TCP protocol will ensure that message 1 will always arrive first (unless there's some man-in-the-middle attacker; yes, he can cause the connection to shut down; there's other protections in place that ensure he can't do anything else).
However, WEP is designed to protect wireless connections; the messages that it protects are datagrams transmitted over the radio. In practice, it is quite common for messages to not be received correctly (because of interference). Because of this, WEP cannot assume that all transmitted messages will be received, and so WEP cannot use a long-standing RC4 key.
A cryptographic protocol needs to meet multiple goals; they ought to be secure; however, they also need to work well with the overall system design. WEP, as designed, does the latter reasonably well; it's just the former they missed a bit.
Your Coursera professor was wrong. Or, maybe you misunderstood him/her. (Hey, it happens sometimes. Nobody's perfect.)
WEP has many, many problems. The worst flaw -- and the best-known flaw -- relates to how WEP (mis)uses the IV with RC4. However, this is not the only flaw in WEP. Your professor's suggestion might eliminate the well-known flaw related to how WEP misuses its IV, but it doesn't eliminate the other problems with WEP. Those other problems with WEP are also very serious. So, your professor's "fix" is not sufficient, and such a scheme would not be safe in practice.
To learn more about a variety of problems in WEP, read the following research papers and blog posts:
P.S. Make sure you read Don't use encryption without message authentication. A stream cipher provides encryption, but not message authentication, so it needs to be combined with a MAC (message authentication code) if you want it to be secure.