• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Help: Mac as a Terminal
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >Help: Mac as a Terminal (From: Brent Austin <email@hidden>)
 >Re: Help: Mac as a Terminal (From: Colin Cornaby <email@hidden>)

  • Prev by Date: NSTask with admin power
  • Next by Date: Bindings/NSUserDefaultsController issue
  • Previous by thread: Re: Help: Mac as a Terminal
  • Next by thread: Re: Help: Mac as a Terminal
  • Index(es):
    • Date
    • Thread