% 今後の課題

%%文書開始****************************
\begin{document}
%%**************************************
\chapter{今後の課題}
ここではリモートエディタの実装において今後開発, 修正しなければならないことについて解説する.

\section{既存エディターに対する編集方法}
ユーザーが自身の好みなエディタを選択し、リモートセッションが行えるためには各種類のエディタのプロトコルをリモートエディタに対応させなければならない. まずはemacs 続いてはvimの実装を予定している. ただし, emacsやvimはバッファの構成がjavaによる自作エディタとは異なり, オフセットによる管理を行なっていないため, 対応させる方法を模索する必要がある.  加えて, emacsにリモートエディタを対応させる際にはemacs-lispを用いる必要があることが予測される. java言語で構成されたChristieからemacsの操作をするまでの処置の方法も模索しなければならない. 


\section{編集するファイルの共有方法}
現段階では編集位置とその文字列, もしくは削除されたかどうかという情報の送り合いしか実装しておらず, 編集対象のファイルの共有が行えていない. ファイルの共有方法としてファイルの中身をそのまま送信すると言った方法が考えられるが, ファイル要領や通信への負担といった要因を考えると最適な手段とは言えない.
そのためユーザが編集するファイルの一部部分のみ送信するといった方法を考案する必要がある.


\section{動的なStar型Topologyの構成機能}
現開発段階では, 編集位置の相違の解消方法の設計のため, Star型の接続をdotファイルを用いて静的に行っている.
 先述したが静的Topologyの構成では参加ノードの数が想定と一致しなければ動作しないという問題点がある.
 作成するリモートエディタは不特定数のユーザの参加を前提としているため, 動的にStar型のTopologyを構成する機能を作成する. また, リモートエディタのセッションでは,セッション開始者とは別にサーバーを立て, そのサーバーに開始者を含めた他のユーザを接続する予定である.

\section{複数のマシンがセッションに参加した際の動作}
現在は一つのマシン上にポートを複数立て, 実際の動作を確認している. これを実際に複数のマシンからセッションを参加した際の通信上でどのような問題や利便性の低下が起きるかが確認できていない. また, セッション参加者にも上限が存在することが予測される.  

%%文書終了****************************
\end{document}