Re: Help: Mac as a Terminal
Re: Help: Mac as a Terminal
- Subject: Re: Help: Mac as a Terminal
- From: Andrew Satori <email@hidden>
- Date: Mon, 26 Feb 2007 20:31:19 -0500
Not to put to fine a point on this, but ....
This is a design decision that should have been made before line of
code was written. That said, now you are boxed in.
Without knowing a bit more about your application, we can only make
assumptions. Generally speaking, a client server design is the model
you are probably looking at, with your data in a server based RDBMS
and you are then accessing it via your Cocoa Clients, running in a
full OSX installation, probably on something like an iMac (which is
smaller than many Network Computer / Thin-Clients). Ideally in a
restricted mode that only allows that application for the default users.
This is the only way you are going to run a Cocoa app on many clients
against a central server today.
Now, this has some limitations, and in the Windows world is
considered very much to be 'old school', having been largely replaced
by n-teir architectures. Most RDMS client access libraries aren't
very WAN friendly. Meaning that you aren't going to want to run your
application over anything less than broadband, and anything less than
ethernet will be a noticeable slowdown, however in an ethernet
environment, it remains one of the easiest and most efficient
implementations, and I'm guessing would be the easiest path from
where you are. Of course, the means a multi-user scalable database,
which pretty much rules CoreData / SQLLite.
Ok, so the short answer is, No, the Mac doesn't support what you are
implying you want. So let's talk about your alternatives.
On Windows, you have Terminal Services or Citrix, which are basically
the same technology with slightly different implementations. In both
cases, your application and database live on a central server. Then
each thin-client connects to the server and creates an 'instance' for
it's workspace, which is a full user login of Windows behind the
scenes, even though only a single application may be presented. The
application is then displayed over the wire to the workstation,
usually in what amounts to sending it over the wire as a screen
scrape. This is neither fast, nor particularly user friendly, nor is
it as cost efficient as people seem to believe. First, you need a
much more significant server to handle multiple interactive
sessions. General rule of thumb, a 4 processor server with 8gb of
ram will generally start to cap out at about 20 clients, and if the
DB is on the same server, performance will tail off much faster than
that.
Then there is the Unix, X-Windows way. This is by far the most
effective thin-client methodology, as X-Windows handles this quite
well, and you can then use inexpensive Thin-Client devices that are X-
Windows clients that actually boot off the network and display
locally. To a certain degree, you might be able to get this working
using GnuStep to reuse some of your Cocoa code in an X-Windows
environment.
Of the non-Mac alternatives, this is also the 'cheapest' as the thin-
client's are more readily available.
This sounds all fine and dandy but let's get down to cases and Cocoa,
because I'll honestly tell you that despite everything above, I
believe that the Mac and Cocoa are your best bet:
Case Windows: $35,950 (round figures no development, support or
installation costs)
Server:
$15,000.00 -- Dell 6850, basic configuration, Windows Server w/ 20
cals
$ 4,950.00 -- Citrix MetaFrame w/ 20 clients
Thin-Clients:
$ 650.00 x20 -- Wyse Winterm 941GXL w/o monitor
$ 150.00 X20 -- Generic 17" LCD Monitor
Case Unix (Sun & Solaris): $23,690 (round figures no development,
support or installation costs)
Server: $ 9,995.00 -- Sun Fire T2000 QuadCore Niagra (left in the
most basic spec, probably adequate for 20 users, barely
$ 115.00 X1 -- package of 25 smartcards for session storage
Thin-Clients:
$ 679.00 x20 -- Sun Ray 2 with Keyboard and 17 LCD monitor, and
session cards.
Case Mac:
Server: $ 7,295.00 -- Apple Xserve, bumped to 146gb disk, 8gb RAM and
dual 2.66, Added unlimited Apple Remote Desktop
for central management of the Mac Clients
Not-So-Thin-Clients: $27,275 (round figures no development, support
or installation costs)
$ 999.00 x20 -- iMac Core Duo
None of these cases address cost of development tools, database
engines, infrastructure or other forces, and these can WILDLY skew
these numbers.
I've done all three of these deployments in my career, they all have
pluses and weaknesses, and there is the possibility of some mix and
match, and more importantly, there is quite a bit to be said for
design decisions based upon the planned deployment model.
I'll address some things that may be relevant. Cocoa is a wonderful
development environment (though in it's current form, access to
RDMS's data requires more work than it probably should). It is also
free per developer. On the Sun/Unix platform, you can use GCC and
and a mix of Open Source like Eclipse, and with Solaris, dtrace is a
wonderful tool. Sun's Developer Studio is a good tool, and I believe
it is now Free as well, though I cannot confirm that, I haven't kept
up with it in the last couple of years. Visual Studio is the tool of
choice on Windows, for good reasons.
On the Database side, you have options from free to very non-free
ranging from the low end with MySQL, to the mid-range with PostgreSQL
and into the high end with Oracle (and a lot in the in between groups
like OpenBase, FrontBase, MSSQL, Informix, Sybase, IBM etc...).
Nearly all of them offer client-server libraries, JDBC or ODBC driver
interfaces.
And that brings the other two options. Use Java and use Java Thin-
Clients (though they aren't in truth 'thin-clients' in that they have
local computers that just execute Java applications). Or write the
entire thing as a web application and use a thin-web client as your
terminal.
In the interest of the best user experience I cannot recommend the
last two options, though plenty of people obviously do (been to the
movies lately and used a self-service kiosk?)
So, hopefully, this gives you some food for thought. I personally
would opt for the Mac & Cocoa, because of the intrinsics and the
development tools. But that is a choice you'll have to make on your
own.
Andy
On Feb 26, 2007, at 7:15 PM, Colin Cornaby wrote:
I'm assuming you're talking about something similar to Citrix or
Windows Terminal Services.
As of now there is no way to do this on the Macintosh. You probably
want to explore writing your own client/server implementation for
your application. Or use an existing solution like the Citrix or
Windows Terminal Services clients for the Macintosh, and simply
have your Macintosh users log into a Windows version of the
application, although this option is not as nice as simply having a
Mac OS X application.
-Colin
On Feb 26, 2007, at 3:41 PM, Brent Austin wrote:
I know very little about terminal/emulation. The reason I am
writing you
is because I have a very specific question regarding using an os x
comp
as a terminal. I am in the process of developing an information
management system that is a native cocoa app with a secure database
backend. What I would like to do, once the app is developed, I
would like
to be able to implement in
the following way: OS X and IMS application installed on main XServer
then have multiple (as needed) terminals that access the main server
and are able to utilize the app and database as necessary each
terminal
independent of each other. What I mean by terminal is a Mac Display,
Keyboard, and Mouse but no cpu. You would just securely login at the
terminal and then have your own instance of the IMS app to do what
you
need. Is this possible on a Mac?
_____________________________________________________________________
_______________
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find
flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
40mac.com
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden