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

[--[ UxBoD ]--]

----- Original Message -----
> 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
> 

IIRC Citrix is able to define by policy whether a user signing is allowed sound or not ... Perhaps they have got their user cases wrong as-well ;)