Web-based IM implementation

Nowadays, most IM software is desktop-based. TCP/UDP is usually used, and both firewall penetration (proxy) and UDP-based NAT penetration P2P technologies are implemented. Is it feasible to create a web-based IM (we do not consider embedding a pseudo B/S like ActiveX control in the browser, because it is actually a C/S, we want to discuss the pure web method )? The answer is definitely yes, but there are some restrictions, because:
(1) Web-based IM inevitably uses HTTP as the main communication protocol. The non-connection and stateless features of htpp make it difficult to manage the status. Of course, the advantage of using HTTP is that it can easily pass through the firewall. (Port 80 of HTTP is enabled for most gateways by default)
(2) unidirectional. Only the client (Web browser) Actively contacts the server, and the server cannot actively contact a specific customer.
What are the limitations caused by these web features?
(1) Direct P2P cannot be implemented between the customer and the customer. Because when it is based on Web, one customer cannot directly "find" another customer, let alone Nat penetration.
(2) The message interaction between the customer and the customer is "Pseudo Real-time", and all messages must be transferred passively through the server. For example, if customer a wants to send a chat message MSG to Customer B, it first submits the MSG to the server because the server cannot actively find Customer B, therefore, the server must temporarily store the MSG (such as storing it in the database) and wait until B sends a request to forward the MSG. This is what "passive" means.
Even with so many restrictions, we can still implement a decent web-based IM, which only requires some simple technologies/techniques.
(1) The client uses Ajax technology to partially refresh the page. If the whole page needs to be refreshed whenever a new message or status notification comes, the Web im must fail.
(2) The client uses a timer to constantly ask the server for new notifications. For example, whether the MSG sent by someone else or the status of a friend has changed. If yes, the information is extracted from the server.
(3) The file transfer function can still be implemented, just like text chat messages. The sender uploads the file to the server first. When the receiver finds that there is a file sent to itself through polling, the file is downloaded.
(4) the video chat function can still be implemented. The first is video capturing, encoding, and decoding. This may need to embed ActiveX-like controls in the browser. Second, video data transmission can be similar to file transmission. Undoubtedly, this method is very ugly.
(5) group function. Simply think about it and you will find that this implementation is relatively simple.

Although we can implement a Web-based IM through various techniques, can it still be well known as "instant messaging? From the previous analysis, we can see that all P2P communication is "pseudo" real-time, and the load on the IM Server when the number of users is a little large can be imagined (especially the video chat function, how much data does the server need to store ?).
Therefore, I can infer from what I know that pure web-based IM cannot be made into a product now (you can write it for fun, of course ). Of course, there may be better solutions beyond my understanding. If you know such a solution, please leave a message to me.
I think, it is true that B/S will never be able to swallow all the territory of C/S, and many applications must be non-C/S.

Http://webmessenger.msn.com/

The Gtalk web version under Google Gmail is good.
You can change the language to English.
In addition, the newly released SNS im of MOP and donews are also web, and the effect is also good.

Http://www.meebo.com
A good web-based IM implementation