Native client is the only trouble-free way to connect
Our support desk continues to receive calls from people trying to connect who are stuck at the "loading" screen and don't know what to do (usually due to not having X11 on a MAC or having a MS version of Java rather than Sun, and not getting any clear feedback or alternatives on the "loading..." screen).
We're getting a lot of pressure to go to Citrix or another solution because of the support costs involved in dealing with the frustrating "loading..." screen.
However, we've recently begun experimenting having PC users download an executable we've put together that includes the native client and a batch script to specify the server and application to run. This has been trouble-free and excellent!
However, Sun is saying it's going to discontinue support for the native client in upcoming versions.
Sun - could you pls tell us if you plan to fix the "loading..." screen issues and enable MACs to connect without X11 OR if you'll keep supporting the native client? I'm definitely going to have a hard time supporting SGD if the "loading..." issues remain unsolved and on top of that the native client isn't available.
Thanks
[1177 byte] By [
cbarbera] at [2007-11-27 2:04:11]

# 1
I agree.Our remote users overseas can only use the Native Client because it can launch apps faster and less display lags with NC over web browser.
# 2
This is a small portion of a correspondence to a Sun representative. Response has not been received to date.
It is a very big issue, Citrix load-and-go, Nomachine carry the client with you SGD "stuck" between MS JAVA - or No JAVA - and Nomachine with JAVA same issue.
begin correspondence
I have been traveling this past week and have a further update for you.
Not one PC in any hotel business center could access the SGD demonstration
applications nor my SGD application website. Since the hotel business center
PC's are were locked down I was not able to acquire any error message from
the JAVA console. or Identify what version of JAVA is loaded.
Once again the SGD display with the left to right orange bar is displayed - no
login screen.
We need to address the overall issue as quickly as we can. In summary - SGD as
it stands with the dependency on JAVA and current PC's configuration does not
appear as a solution to a global desktop - it appears to be more of a
corporate solution with dependency on IT resources.
-end correspondence.
# 3
Sun, can you please let us know what is being done about this?
We're relying on this too as a "global desktop." If we just wanted something for inside the corporation we'd just use terminal services. This is supposed to be accessible from any client any time, and that is increasingly on locked down computers.
# 4
I've had very few problems with systems not having Jave, but I agree, there's got to be a better way. Although, Citrix is no better... It may not depend on Java, but it has other browser dependencies that have failed on me...
# 5
Sun - the release notes for 4.31 say that in the next version you will discontinue the native client. Hoping to get some clarification. This is worrysome because:
The tcc.exe client:
-causes users to get stuck at the "loading" screen without any feedback
-requires the use of a browser which is often locked down and presents its own problems
-often has 4 security prompts for a first time user - a daunting task for a new user and something that often requires us to be on the phone with them which costs us money.
On the contrary, the native client:
-can be part of a small installation package that, when run, runs a command file that runs the native client and tells it what application to launch.
-There is only 1 security warning and no browser issues at all
THE RESULT IS THAT THE NATIVE CLIENT REMAINS THE ONLY CONSISTENTLY ELEGANT WAY TO CONNECT TO SECURE GLOBAL DESKTOP.
SUN - please let us know if the future release will provide an equally elegant way to connect (As few as possible security prompts, no need to use browser, etc)
Thank you!
# 6
The new version, 4.31, seems to go part of the way, but not all the way toward fixing this problem:
1) On PCs with java enabled but an older JRE, it now forwards to a page suggeting that they upgrade. This is great b/c we can replace that page with a custom page that allows the user either to upgrade the JRE (which could take 10 minutes) or to just download the native client to connect immediately. THANK YOU
2) However, if java is not enabled, it still says "please use a java-enabled browser" and our users of course don't know what that means or what to do about it.
ALL I WOULD ASK IS THAT IF JAVA IS NOT ENABLED THAT IT ALSO FORWARDS TO THE PAGE ABOVE. Then we can give the user options to allow them to connect immediately without having to go into their browser settings to enable java, which often times requires the help of an IT person or for us to be on the phone, both of which prevents immediate connections.
So...we're almost there. Sun, any chance of achieving number (2)?
Thank you
# 7
I finally decided to try the native client, since others seem to like it, but I can't get it to work at all. What's the trick to get it to do anything other than generate errors?
# 8
are you using
http://servername/tarantella
as in
https://sgddemo.sun.com/tarantella
the /sgd URL can not be used with the NC . . .
I would stick to the /sgd client, it is basically the NC in a browser and when the NC goes away you won't have to re-educate users . . .
# 9
Carmelo - any plans to have update SGD so that if you are using either an older version of java or your browser is not java enabled that it forwards to another page?
This is all we need to get things working.
Then we can create a custom page that it forwards to and a user can be instructed to download a package that runs the client from the command line without java.
Please let us know. This is all we need to make a great product better
# 10
Tried it both ways and it still didn't work. Odd.Don't worry, wasn't planning on deploying to end-users :-) Was just curious about it and thought I'd play around with it some!
# 11
> Tried it both ways and it still didn't work. Odd.
>
> Don't worry, wasn't planning on deploying to
> end-users :-) Was just curious about it and thought
> I'd play around with it some!
Hi.
Well, perhaps I missed something but could you please tell me the problems you're facing with the SSGD client?
I've recently installed SSGD 4.31.905 and everything is working as expected.
Thanks,
Rob