On 11/09/2010 08:04 PM, Gregory Maxwell wrote: > On Tue, Nov 9, 2010 at 1:12 PM, Dennis Jacobfeuerborn > <dennisml@xxxxxxxxxxxx> wrote: >> On 11/09/2010 06:12 PM, Gregory Maxwell wrote: >>> I've mostly been watching here and I think people have been fairly >>> clearly about their concerns: Network transparency is important to >>> them, and they understand that the wayland message is that it will not >>> be supported. This message has been clear enough to me here and >>> elsewhereâ with people arguing things like applications which need >>> network transparency are all now web based. >> >> You are mis-interpreting the message probably because you are not a >> developer and as a result don't know how software is designed in layers. >> Wayland handles the visual aspects of the desktop. Networking doesn't >> belong there. A remote app layer will sit on top of Wayland and deal with >> the communication between both ends. > > Nice way to assume. Its pretty likely that you use software I wrote every day. > > So long as the _system_ provides robust and fully integrated network > transparency I don't really care which sub-components are actually > providing it. I think I already made that clear enough. I don't think > anyone here really cares about the internal details so long as the > functionality works well and is well integrated. > > What hasn't been made clear to me so far is that this is the case. I > see you saying this, it's also argued that network transparency is not > required in wayland because some toolkits will support falling back to > X. Other people have argued that network transparency is no longer > required because of the existence of web applications. > > If is so clear-cut for wayland then why can't a clear message be provided? > > Please don't blame me the lack of clarity in the communications on > Wayland's intended capabilities and confusion that other people have > created by arguing the network transparency isn't a requirement. > > Miscommunication happens. It doesn't even require anyone to be > uniformed or incompetent. > > I'm perfectly capable of understanding a statement like > "Cairo^wWayland is just a rendering layer, the communications is > provided by FooBar, and that will provide good network transparency or > at least as good as X11, so there is no need to worry if network > transparency is important to you." From what you wrote it sounded like you were specifically insisting that the network transparency bits were supposed to go into Wayland proper and that would make some sense if said but someone who has never developed software and doesn't understand the layering of subsystems. It was an honest mistake and not an attempt to get cute. My apologies. What I was trying to get at is that even if the Wayland developers completely ignore network transparency that has no bearing on an independent implementation of that feature (see Casey Dahlins example elsewhere in this thread). [snip] >> X will run as a Wayland client. That means all applications that support X >> will be able to run remotely without change. Since QT and GTK both run on X >> and virtually all apps out there are programmed to use QT and/or GTK for >> most people nothing will change in the next couple of years. > > This is exactly the sort of non-comforting communication that I was > complaining about above. > > The fact that 'legacy' apps will continue to function in a network > transparent manner for some time is nice thing... but it suggests a > future which will be increasingly boxed in if it becomes a central > component of common GNU/Linux distributions. > > You're giving a really confused message here. In some parts of the > thread it's being argued that the complaints are unfounded because the > system will provide network transparency, but it's also argued that > transparency isn't required because old applications will continue to > work the old way, or because people don't actually need the > functionality. The reason for the confusion is that two cases are conflated here: Wayland + X and Wayland without X. As long as X is present as a client on top of Wayland all apps will just continue to work as usual. That is the initial state of affairs and "native" network transparency for Wayland is not going to be that important. Once Wayland is established and successfull people will eventually want to get rid of X altogether. At this we'll need an X-less way of doing network transparency. This point lies 2-3 Years in the future though so it's not necessary to get worked up about the details just yet. >> That's why it's so hard to understand why people are already bringing out >> their torches and pitchforks over this. > > Keep your windowing system out of my network transparency!!!! ;) > >> Now let's assume Wayland is really successull. In that case people will >> want to get rid of X altogether and then you'd also lose the remote app >> support of X and in that case you obviously would need a replacement for >> this so apps can run remotely on an X-less Wayland desktop. > > I think it's needed on the first day that wayland desktop applications > are widely deployedâ someone shouldn't have to choose between the > "wayland ui" and network transparency. > > I suppose there is plenty of room to disagree with this but I would > point out that other operating systems have not had a lot of luck with > after-the-fact network transparency. For me it's not a case of disagreeing since I also would like to see a remote apps feature but the first release of Wayland in a mainstream capacity lies probably a year in the future so there is plenty of time to talk this through yet some in the thread have already decided to paint the future pitch black and that's a bit surprising to me. > Remote X is actually pretty terrible from a protocol perspective. It's > very chatty. But at least on a reasonable network (and by reasonable I > should note that doesn't just mean a local network) it's quite usable. > It would be sad not to make an _improvement_ on this, but I really > can't see how something could even match it without having it as a > design consideration at the start. What I think makes this case a little different is the fact that the introduction of a compositor makes the drawing of an app window and the drawing of the desktop two distinct operation. Traditionally all windows were rendered directly on the desktop so either you'd have to redirect that (which is basically what X does) or you'd have to redirect the entire desktop (which is the VNC way). In the "new world" the app draws into it's window and the compositor is invoked to put the desktop together. This gives you the ability redirect the drawing of the window to a remote desktop where the compositor will then render it onto the desktop. What I specifically like about this is that it allows for a better separation of concerns and allows both the core display code and the "remoting" code to progress idependently. New methods for the network part don't have to worry about specifics of the display part and vice versa. X seems to be a giant wool ball where all parts are so interdependent that it is difficult to advance one part without breaking another. That is why I think that not wedging the networking bit directly into Wayland is a good thing. > I don't mean this as an insult or a lack of faith against the people > working on the systemâ the same pattern of treating network > transparency as an afterthought has not worked where anywhere as far > as I can tell. > >> What's puzzling is why people are willing to form hardened opinions on >> things they apparently don't understand. It's baffling. > > The only hardened opinion I have is that network transparency is an > essential opinion. Beyond that I have no clue. I'm waiting to be > educated. If only Adam Jackson were responding I would have walked > away satisfied by now. Perhaps I should ignore everyone else. :) Well he seems to be quite happy that Wayland is coming which gives me even more confidence that the future is more positive than some make it out to be. :) Regards, Dennis -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
