I am creating a web application that updates the HTML content of each client's web page, for one Objective based on changes made by the customer I am using Socket.io of Node.js so far.
I am using HTML5's contractual property so that the client can manually edit the content of those components for which I also want to update for other customers.
The problem I am facing is that I do not understand what data to send to the server to send information to the server and other clients of changes made in return for it.
By adding and removing each character, sending the entire insular HTML means sending huge amounts of data to websites that are in poor performance and slow speeds. There is no substitute for sending embedded data because we do not know what position it has been added or deleted or edited in the Diva element.
Note that the use of the keyboard is not the only way the clients can change the HTML content of their copy of the web page, the data of the required devel element changes based on many activities using the client's JavaScript. is.
Now I should know how I can send exact information changed on the website on slight changes to get real-time experience. / P>
PS I intend to not use any existing module like Share.js but suggestions are welcome.
It is not really a "question" instead of discussion and "brainstorming" will be the type of subject That is quite a matter of opinion, because there is no specific way of doing so much talk on this subject.
But I will take the chance, and the way I will contact this to my pure IMHO
- Text Version Control - Text versions One way to keep track of, like some similar git, but instead of using character positions instead of lines. The version of each editable text should be controlled, a "master" that merge things, and notifies customers of newer versions. On the client side, variation in versions (comits) should be implemented in the same way as the server merges.
- Structure Update - This is slightly different, because the update of the structure contains only HTML structure, and the version is not required (there is still a possibility that you want to apply , Or at least some of the history work, and racing conditions). The editing structure will inform the server of such changes. It should be ensured that all clients are "on the same page" in relation to the structure.
- Referrings - It can be difficult to refer to HTML elements (selectors), but there is a complexity - when
; & Gt; Many with - Servers & lt;> Customer Politics If you are completely talking about the syncing experience, then you have the official politics of communication The only server where the server decides to actually do things, and the client renders and only provides some input (request). For example, when the client wants to add an element to the HTML, he sends the request and then the server decides such a way, and inserts it, once it comes in, then it will publish such an event and then the element The client will appear on the element and then they can edit the content about it. You can "move ahead" without waiting for the server, but instead of part of the main argument it should be done as an additional layer.
- When a customer is working on node (element / text), it can only work on it (commitment to stop) commitment "in progress" And this single version should be committed. In the beginning you can edit the text or an element once the user has "done". And later add real-time visualization capabilities to this kind of process.
- You have to research the amount of traffic that will apply it. With version control and event-based element editing - this would be very efficient, but the cost would be that the server side actually emulate the entire DOM structure and not the merge and other stuff.
Then this is primarily opinion based, and not a small subject, it covers many areas, I think that is not "fastest", "pure" and "good to target" "As an approach, some trades can be a very easy solution.
Comments
Post a Comment