[X2go-dev] upcoming release

[R P Herrold]

On Sat, 20 Feb 2010, Heinz-M. Graesing wrote:

> for the last months we've been working on a new release. First we
> thought to bring some new features, but now we'll bundle it, because
> there where many changes needed.

> It still will take some time to the release, but we wan't to inform you
> on some changes we are discussing.

hmmm --- so the roadmap is non-public, or not being developed 
in the open?   Doesn't this imply that this is not:

>> What is x2go?
>>
>> x2go is an open source terminal server project

but rather a commerical project, that permits non-insider 
people to watch it develop in the open, under a 
non-encumbering license?

I am not trying to be argumentative here, but to have a 
internal roadmap that is not comminucated in its development 
or implementation seems to imply a problem in project design

> First of all: We are planing a multi session x2goclient for the release
> after the next release. So there will be a lot of work of redesigning
> our clients. This would be easier with only one client architecture and
> as the Qt client is our base for the Linux, Windows, Maemo and Mac OSX
> platforms, we are asking the question:
>
> Would it be ok to focus our work on the Qt client and to stop/reduce our
> work on the GTK client?

The counter-view, is that if it is difficult at the 
presentation layer to adapt to multiple widget sets, this 
probably means that the API boundries are not well defined, 
and need rethinking.

A customary three-tier model usually has a presentation front 
end, a application logic layer in the middle, and a data store 
in the back.  There are well defined boundries at each 
interface point, so that one can substitute (and add capacity, 
facility for failover, and fanout) at the needed point 
independent of afecting the other two.

The weblog poll asks:

>> Can a terminal server be part of "desktop virtualization" or 
>> will there only be virtual machines for every user?

and I suspect I am the only vote for 'No, (other reason)' 
where the 'other reason' I have in mind is that a 
administration console should be just anohter instance, albeit 
with specifl rights, AND, that the reason: 'Yes, because it 
will help administring huge amounts of users!' implies pretty 
clearly that Command Line API, and 'curl' and related 
'web-like tools support (fr automated provisioning and 
management [or even leveraging the present LDAP backend into 
something like GOSA is not being considered]

> If we would go on developing both clients equally, it will really take a
> long time to implement all new planned features and this will slow down
> the whole project. The Question can also be transformed: Is there
> anybody interested to help us to keep the GTK client up to date?
>
> Please tell us your thoughts but keep in mind, that the Qt Toolkit is
> available on all major distros and we'll keep on developing our Gnome
> bindings. This will not be a preconfigured "choice of Desktop Environment".

The competition between the two FOSS modern widget tool kits, 
is that this pretends that, say, Tk/Tcl, OpenMotif, or 
wxWindows do not exist, and that one HAS to choose to stay 
with the latest bleeding edge 'coolness' to access some 
'latest new feature'.  That alone is a clear warning sign of 
API boundry bleed-over, and over-tight integration to one 
implementation mothodology

> So we think we should now continue with some of the new features of the
> next release (as a contrast):
>
> Yes, there will be a Browser Plugin. It will be realized  as a
> "sponsored development" so we'll get some money for our work and the
> sponsor will be named.

> You'll be able to integrate the plugin into a Website and you'll have
> all features of the x2goclient.

but part of implementing this is clearly solving a design of a 
webbish API to do the GETS, POST, and PUTS, possibly with 
'REST' and Web 2.0 hotness.  If web control actions cannot be 
specified into a series of atomic actions of this sort, one 
runs the risk of accidentially designing an API model where 
some state is preserved at the client, rather than only at the 
servers

> Yes there will be a "session sharing" option without the need of a LDAP
> server.

I guess I am confused here - how is a LDAP server on 127.0.0.1 
harder to get going that hte pgSQL database.  If the complaint 
is 'it is too hard to set up, this is a symptom of:
 	write a better setup and diagnostic wizard
, rather than:
 	remove the facility

What am I missing here?


>The new "session sharing" option will make it possible to share
> a x2go session with another user, to share a already started xorg
> session with another user and to share a session with more than one
> user. There will be a system tray application which will help
> configuring the sharing settings.
>
> After getting so many mails about a wiki for documentation - yes we are
> working on a wiki which will replace the odf/pdf/html manuals.

but how does one credibly version here -- the problem with 
wiki's is that the end up with locked pages for some to edit, 
and open pages that gather spam, som one cannot simply print 
the 'pdf' that a wiki might offer to produce of an entire 
site.

.. and what is wrong with documentation tools like the older 
TeX / LaTeX, or the later DocBook, which are designed for 
version control system friendly collaborative editting?  I 
think a wiki is the wrong way to go for ystem documenation 
deliverables [having fought this battle and lost in my work 
with CentOS]

> We are looking for new localisations. If x2goclient is not available in
> your language and you want to translate it, please let us know (on the
> list ). We'll provide a *.ts file for your language (qt-linguist).

and again, this is a 'one tool kit' specific solution, rather 
than the FSF .po file approach which is generic.

> We'll announce the the release here on the list and on our blog - at the
> moment we can't tell you when it'll be ready. So please stay tuned and
> tell us what you think about the news...

;)

-- Russ herrold