[X2go-dev] Wishlist: x2gofeatures query before session start

John A. Sullivan III jsullivan at opensourcedevel.com
Mon Mar 21 15:30:55 CET 2011


On Mon, 2011-03-21 at 14:38 +0100, Moritz Struebe wrote:
> On 2011-03-21 14:27, John A. Sullivan III wrote:
> > Performance in a WAN environment comes immediately to mind. 
> 
> 
> Seriously? You must disable flash, vlc or any other video-support, too. 
> Oh and don't forget Opera, Chrome, etc, which repaint the screen every
> time you scroll..... (BTW: FF is doing it right....) You can easily
> limit bandwidth per user. Then the user can decide between
> responsibility and sound.
> 
> >  One may
> > also have restrictions about noise in the work place but, if that were
> > the case, one would probably disable the sound devices on the physical
> > computer 
> 
> ACK!
> 
> > - then again, some other user may have a use case where it
> > legitimately makes sense to conform to noise restrictions by configuring
> > the X2Go server - John
> 
> No you are generating absurd use-cases. One shouldn't have to use x2go
> to enforce this. And then again the right way of doing this is to forbid
> remote pulse-audio connections locally!
> 
> I have the feeling that these requests are not to support x2go, but to
> be able to enforce a business-model (For sound you have to pay 10 bucks
> extra). But what do I care, as long as this is optional and having such
> a handshake is optional......
<snip>
Sorry, I disagree but that is a choice of development paradigm.  Take my
advice from whence it comes - I know very little about development and
the costs associated with it but I do know about managing the end user
side.  To say the user can decide assumes it is a user decision on
one-off installations for savvy users with no central administration.
Now, there may be better ways to disable the transmission of sound than
via X2Go but, in my limited development experience, I've always tried to
admit that I may not be able to foresee every possible plausible user
case and thus try to provide more rather than fewer options.

These are not absurd user cases and they are not fostered by a business
model (in fact, I really didn't appreciate that comment but I may have
taken it the wrong way).  They are fostered by real world working
experiences where sound may be undesirable.  Again, there are probably
better ways to do this than via X2Go as I mentioned in my original
comment but I cannot foresee all cases and there may be a time when it
is better to handle it from X2Go.  Thanks - John




More information about the x2go-dev mailing list