iPhone/iPad が非常に普及した原因は、私たちのパートナーが新しい要件を持っていることです。
これらの問題は AppleScript (つまり、iMessage の送信) で解決できますが、このスクリプト システムは企業向けの準備が整っているのでしょうか? つまり、
あなたの経験と洞察を共有してください。
@Jesper: Scripting Bridge には問題があり、appscript と RubyOSA は事実上死んでいるので、それらを推奨するべきではありません。
...
@boj: AppleScript 言語自体が「エンタープライズ対応」であるかどうかを尋ねるのは間違った質問です。あなたが尋ねるべきことは次のとおりです。
「デスクトップ ハードウェア上で動作するデスクトップ ソフトウェアから、信頼性の高いヘッドレス システムを構築できますか?」
と：
「サーバーサイドでAppleは正しい選択ですか？」
iOS はコンシューマー向けの優れたモバイル プラットフォームであり、OS X は適切なデスクトップ OS である可能性がありますが、サーバー ルームに関する限り、それらが絶対的な最後の唯一のオプションでない限り (たとえば、行き詰まっている) OS X Server のプロプライエタリ サービスの 1 つを使用しており、他の代替手段はありません)。仮想化は良い考えではありません。LOM やラック対応エンクロージャなどの IME およびエンタープライズの基本は、初心者には向いていません。また、事前の警告がほとんどまたはまったくなく、製品ライン、機能、およびサービスを突然/抜本的に改訂する Apple の傾向を忘れないでください。エンタープライズ レベルの安定性、予測可能性、およびサポートが必要な場合は、Linux および/または Windows boxen に固執してください。
あなたの場合、iMessageの使用について話しているので、それは1.独自のプロトコルであり、2.Appleはこれまで基礎となるAPIを公開していないため、選択肢が本当に狭まります. おそらく最初に自問する必要があるのは、オープンであり、エンタープライズ レベルで既に十分にサポートされている SMS で適切なソリューションを実現できないと確信しているのかということです。そのための強力なビジネス ケースを作成できると思います。運用コストが少し高くなる可能性がありますが、安定性と信頼性、および (希望する) 専門的に構築されたシステムに対して支払っていることを指摘してください。
Messages.app を中心に構築するものは、比較すると、アマチュアのラッシュアップになります。その道を強いられた場合は、調査を行い、事前に約束をしない方がよい. 例えば：
システムに障害が発生する原因は何ですか (たとえば、ヘッドレス ボックスでポップアップするアプリケーション ダイアログは重大な PITA であり、アプリケーションのクラッシュ、接続の問題、およびボックス自体の死を含むその他の可能性を軽視しないでください)?
どのような種類のダウンタイムが見られますか? また、障害が発生した場合のコストへの影響は何ですか? (つまり、このサービスに期待する SLA は?) リモートでビジネスに不可欠な、または企業が要求する 2 ナイン (99.9999%) 以上のアップタイムが必要な場合は、既存のソリューションに足を踏み入れてください。
何か問題が発生した場合にシステムを回復/再起動するためのオプションは何ですか (たとえば、自動化されたフェイルオーバーを陪審員にしようとするか、リモートでボックスに誰かを入れて修正を試みるか、オンサイトの管理者にサイクルを任せますか?パワー）、心配する必要があるデータ損失やその他の問題はありますか？(たとえば、ビジネス ロジックとデータベースを別の Win/Linux ボックスに保持して、OS X ボックスが再生/再起動されたときにシステムがどこにあったかを追跡できないようにすることができます。)
システム メンテナンスに関する取り決めは何ですか。連絡が取れない、またはもうそこにいない場合、他の誰かがコードや展開されたシステムをあなたなしで看護することができますか?
ところで、WWDC と 10.9 はそれほど遠くないので、AppleScript と Messages.app に時間を費やす前に、iMessage API が 10.9 で公開されるかどうかを確認するのを待つことをお勧めします。メッセージング API が開かれている場合は、ObjC でより堅牢なサービスを構築できるようになりますが、それを開発して実行するために OS X に縛られることに注意してください。