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

Mike Gabriel mike.gabriel at das-netzwerkteam.de
Mon Mar 21 22:27:16 CET 2011


Hi John, hi Morty,

On Mo 21 Mär 2011 15:30:55 CET "John A. Sullivan III" wrote:

> 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

I'd also like to see rather more than less features and quite an  
amount of flexibility in X2go.

I think X2go is a piece of software that can have many different use  
cases and none is less worth than another. We should make sure that we  
- as developers - work in such a generic way that we meet requirements  
of a broad mass of people. If we need a very special feature for our  
own use case, let's find abstraction layers to make the code as  
generic and flexible as possible...

That is: A ,,No - we (personally) do not need this feature'' should  
not end up in: ,,No - we will not include this feature''.

Greets,
Mike


-- 

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20110321/d815d212/attachment.pgp>


More information about the x2go-dev mailing list