Bugs and Suggestions

Your first point is the best argument against implementing it into Telegram, the second just shows how little you understand.

You say it yourself, office suites may ask have a common framework, but still they are separate programs. And it becomes even more obvious with toolchains like the adobe creative cloud and similar.

And your other two examples are just ridiculous.
Browser: it incorporates everything that is necessary to do what they are supposed to do: browse the web, do it's obvious they have to put everything into one program. It's debatable if they should e.g. support running wasm programs or if that's better off in a separate program, but other than that, they only include what's necessary. Remote desktop is not necessary in Telegram.

IDE: are you serious? Only because it's one UI doesn't mean it's one program. An IDE is always a collection of command line tools under one UI. And here too, they include everything that is actually necessary to build a program. Again, remote desktop is not vital for Telegram to make sense as a cloud messaging service.

Emilia Mar 14, 2021

Richard Rosner

1) Why? Dwservice is a really good service, but it is not comparable to other proprietary solutions.
2) Are you talking about you? Do you know what is a framework or library? Are you saying the office suite do not shared library and code? No a browser includes a lot more features than simply browsing the web. Maybe you are still in 2000. Of course, we can talk about if you like or not to see remote desktop in telegram, what is really necessary? In your opinion even conference call and live streaming is not necessary. In my opinion you are wrong.
IDE: did you read what I wrote? I think no. We are talking about the code complexity about developing and maintaining one single program or suite of programs that share a common framework, libraries and code with respect to a N independent programs.
Is remote desktop vital for telegram? No. Is it an useful feature? Yes.

When dwservice is already that good, what are you lamenting about then?

And no, it's not better to have everything in one program. It should only contain what it needs. Everything else would make the code unnecessarily large and thus harder to read and debug.

Of course one could write a remote desktop program ontop of the same technology as Telegram, but it should be in a separate program. And when you share frameworks or libraries between programs, you don't get bigger code, you merely reuse/duplicate code. You just have to make sure that patches are always included for both.

But that would mean that there would be any reason for Telegram to build a remote desktop application on top of the technology of Telegram, which will not be the case. If you want it, write it yourself. You said yourself, the Telegram clients are open source. But don't expect them to waste any resources of their servers for that

Emilia Mar 15, 2021

Dwservice is the only viable alternative to famous proprietary software even if it has some missing features (in particular related to communication).

No, again. If you have a single program or a set of programs that share a framework, libraries and code, the design, developing and maintenance costs are lower with respect to a set of N independent programs.

Right, this is what I'm saying since the beginning, please read it. In particular, some features, as remote desktop or drive client, could be directly integrated into the desktop application.

Again, as I wrote you before, the server resources required for a remote desktop session are not more heavier than a video call. Some of resource intensive features for servers are conference calls, streaming (live or not), channels, huge groups.

Richard Rosner Mar 15, 2021

I see, you just don't want to understand anything.

Fact: Integrating more than necessary into one program is not efficient and not helpful for maintainability. Even if you refuse to believe that, it's still a fact. You should only put together what belongs together and not just cram everything into one piece of software just for the sake of being able to. This doesn't apply here.
Fact: Thus a Remote Desktop Application should not be included in Telegram, even if it would be built on top of the same kind of technology. Compatibility and integration into the UI: yes. Built into the Client: no.
Fact: I never said conference calls or Video Streaming would have a less heavy impact than a remote desktop session. But a 1 on 1 video call can since you can reduce the video quality much more before it becomes unusable. And sound needs much less bandwidth. But that simple channels/groups would take up more resources is just ridiculous. Maybe for the few seconds it takes the server to push the messages into the different peoples chat history and send them all, but if you are not sending multiple messages per second you won't come anywhere near the resources it takes for a remote desktop session. At least if you want it to be actually useable.

You are talking about something that you do not know.
Have you ever studied about software engineering, software development, design pattern, etc.?
According to your answers no.
1) Please read again what I wrote several times: "If you have a single program or a set of programs that share a framework, libraries and code, the design, developing and maintenance costs are lower with respect to a set of N independent programs." You have to consider for instance software metrics (LOC and function points), COCOMO cost model, etc.. You can read a good book "software engineering" by Ian Sommerville.
2) I think it would be very useful. You do not agree. I respect your opinion even if I do not share the reason.
3) You can reduce video quality even in remote desktop, many software support it, dwservice included. Again, you do not read what I wrote: big channels and groups. If you read Durov chat https://t.me/durov/153 and https://t.me/durov/142, big channels and groups are the most expensive features of telegram at the moment. Telegram is going to introduce ads in order to pay the cost for them.

Please before to reply without reading, think about it.

1) I'm not talking about money, I'm talking about real life facts. I couldn't care less what costs some ridiculous model says would arise wich clearly doesn't take real life into consideration. Simply, more lines of Code in one Project lead to less readability and thus worse maintainability. That's why you put only code into a project if you need it for it. This is why you wouldn't put a remote desktop application inside a messagin service. You would duplicate what code you need and do that as a seperate project. And keeping shared the libraries and frameworks in sync is only the work of good project managing software. So actually you save money, because code is more easy to read and you much easier find errors. Thus, consumers are more satisfied and it's more difficult to hack the software. Thus less money/time has to be invested into additional security measurements wich would prevent hacking in the event of found security issues.

being useful is not the main question, but if something like that should ever be included into Telegram.

And yes, big channels and groups are the most expensive features. But only the sum of them. Not individually. If you add the ability of remote desktop features, you have to consider that it will be used. Possibly a lot. And the sum of ressources that will take up will very likely be much larger than what groups can take up. At least if it's actually used. If not the ressources to implement it will be even more of a waste.
And I never said it's impossible to lower the bandwith necessary, it can easily be done by using more efficient codecs. But there is only so much you can do before it becomes unusable because you can't read stuff. On video calls you can get even lower, you don't have to be able to read anything. a 360p feed is enough for that in the worst case, but unuseable for remote desktop

ℚ Jul 31, 2021

this feature is a joke.. have u heard about concern separation? its already ton of useless stuff in telegram

you can manage servers and devices with bot interface

rooshoes Jul 31, 2021

I cannot think of a worse idea for a security- and privacy-focused application than giving it system-level remote control. This would undoubtably be exploited. Please do not do this.

34161 Cards

Log In