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." [snip] >> In any case, I can't see that there has been any real concern raised >> about _change_. Fedora is full of change. People are raising and >> arguing specific concerns about the nature of the changes. Please >> treat your list co-habitants with a little more respect. > > Then why are people already calling for the rejection of Wayland even > though Wayland is still far from being finished and hasn't even touched > Fedora yet. > > raising concerns != screaming the sky is falling Well _I_ certainly didn't intend to call for a rejection of waylandâ it seems to be far too immature to even talk about rejecting it at this point. But I think Fedora ought to make clear that network transparency is requirement. It seems that at least a few people in this thread don't believe that it is, and I think that ought to be cleared up sooner rather than later because I'd hate to hear that a lot of effort was put in building a system that won't really meet the needs. If the need for network transparency is already well understood then I don't think there is much more to discuss. [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. > 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. 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. 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. :) -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel