Google Chrome 35 以後的連線架構

[u881831]

Windows 下 Google Chrome 35以後非商店的擴充套件都被封鎖了，
目前暫時的解決方案有兩個，
一個是用開發者模式載入擴充套件；
另一個是用群組原則強制安裝套件，
事實上設定群組原則的方法沒有很複雜，
從Google下載範本後，
直接在群組原則設定介面填入套件ID就好了。
對這兩個方法的細節有興趣的可以看：
http://u881831.blogspot.tw/
詳細步驟在那個頁面的最後一段。

正規的方法除了在商店上架之外，
還有把擴充套件改成Apps，
之前我有寫過，
因為這種架構只能開在獨立的視窗，
不能開在瀏覽器分頁裡面，
所以這種架構的版本暫時擱置；
https://drive.google.com/file/d/0B-K9h3GKW2VGbUJrWHJZSkVOTTQ
另外就是把擴充套件改成一般網頁，
這樣一來除了message passing API 以外的擴充套件API 都不能用了，
https://developer.chrome.com/apps/messaging#external-webpage
有些功能必須要將程式碼整段重構，
甚至有些功能完全不能使用。

之前 PCMan有提幾個備用方案，
其中一個是用node.js 在客戶端架伺服器，
再不然就是在外面另外找一個伺服器。
這次出問題的是主程式而不是socket連線，
不過還是可以用這兩個方法建立一般網頁架構的主程式。
使用外部網頁伺服器的話除了不能在內部網路使用外，
也有伺服器或是網路掛掉的風險。
如果要在客戶端架簡單的網頁伺服器的話，
因為GC的socket api支援伺服器端連線，
而且Google有提供簡單的範例，
https://github.com/GoogleChrome/chrome-app-samples/tree/master/webserver
所以我就用這個範例建立新的架構。

首先我先將這個範例裡面的socket api改成新版的，（GC 33 起支援）
我原來的socket agent也改用新版的api 並整合到這個範例裡面。
新版的api 可以監聽onReceive 事件，
不用自己寫迴圈read socket ，
執行效能有很大的改進。
然後我把伺服器的DocumentRoot改到套件裡面，
這樣所有程式碼就包在一個單一的.crx裡面，
使用者安裝的步驟就更簡單了。
下面是我初步的成果：
https://drive.google.com/file/d/0B-K9h3GKW2VGUG92TlB2QUV4Uk0

使用方法：
App 安裝完成後在App 的介面啟動網頁伺服器，
（可自由選擇本地連接埠）
在GC開啟下面的網址：
http://127.0.0.1:8080/#ptt.cc:23
沒打BBS 網址的話預設是連到PTT 。
因為一般網頁不能設定右上角的popup 視窗和omnibox 關鍵字，
所以連線方法只剩手動輸入網址或是使用書籤。
另外大部分的功能都還沒實作上去，
只有最基本的功能而且只能用熱鍵使用：（因為不能設定右鍵選單）
有選取區域時ctrl + c複製；
ctrl + shift + v貼上；
ctrl + shift + a全選；
ctrl + shift + s搜尋。（只有google搜尋）
App 的視窗不能關掉，
關掉的話網頁伺服器和telnet連線都會斷掉，
另外用完BBS 要關掉App 視窗的時候，
請記得先按Stop關掉伺服器。
telnet連線的開關和網頁伺服器的開關整合在一起，
因為之後預定要套用目前版本的架構隱藏App 的視窗。

這個版本只能算是技術預覽版本，
而且因為程式架構的改變，
需要不少時間才能將所有能實作的功能加進去，
所以這個版本還不適合一般使用者使用，
有興趣的開發者可以把這個版本當作範例改善自己的程式。
另外目前的架構還可能會更改，
比如說使用websocket 伺服器而不使用google的message passing 的話，
甚至可以在Firefox 或是IE瀏覽器視窗使用BBS 連線。
（Google也提供了websocket server的範例）
https://github.com/GoogleChrome/chrome-app-samples/tree/master/websocket-server
不知道大家對這些架構或是程式本身有什麼看法？


On Friday, June 13, 2014 10:22:38 AM UTC+8, ettoolong wrote:

在chrome的捷徑裡面加上 --always-authorize-plugins 可以不會顯示那個警告.

u881831 <u88...@hotmail.com> 於 2014年6月12日 下午10:37 寫道：

現在windows 下非Google商店的extension 都不能用了，
http://blog.chromium.org/2014/02/make-sure-to-get-your-extension-in.html
windows 的使用者目前有兩個暫時的替代方案：
第一個是用開發者模式載入未封裝的extension ，
主程式pcmanfx-gc-0.0.5.170.crx解壓縮載入後，
pcmanfx-gc-socket-0.0.1.170.crx不需解壓直接安裝，
（socket app是屬於apps不是extension 所以暫時沒有被禁）
所以只要在socket app內填入未封裝extension 的id就能和原來一樣使用了，
（未封裝extension 的id是隨機的）
不過每次打開GC時都會跳出警告要你停用未封裝的extension ；

第二個方法是用群組原則安裝套件，
這個方法本來是給大公司或教育機構的網管用的，
我們這邊要另外找一個網路空間放.crx和描述安裝資訊的.xml，
xml 的格式和下面網頁所用的一樣。
https://developer.chrome.com/extensions/autoupdate
這部分我還沒有弄，
假設這部分的網址是
https://pcmanfx.googlecode.com/files/pcmanfx-gc-update.xml
https://pcmanfx.googlecode.com/files/pcmanfx-gc-latest.crx
xml 的內容是
<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
  <app appid='kakincoohepfppgfdfhdbjpmhbelkiho'>
    <updatecheck codebase='https://pcmanfx.googlecode.com/files/pcmanfx-gc-latest.crx' version='0.0.5.170' />
  </app>
</gupdate>
另外pcmanfx-gc-latest.crx 的manifest.json 也要加入
"update_url": "https://pcmanfx.googlecode.com/files/pcmanfx-gc-update.xml",
日後更新版本時才會自動更新。
使用者端似乎是先裝完群組原則範本後，
http://allgoogletesting.blogspot.tw/2013/10/install-chrome-group-policy-api-on-windows.html
（非官方網頁）
按照下面的說明在本機群組原則編輯器裡面修改，
http://dev.chromium.org/administrators/policy-list-3#ExtensionInstallForcelist
這邊要填入的值是
"kakincoohepfppgfdfhdbjpmhbelkiho;https://pcmanfx.googlecode.com/files/pcmanfx-gc-update.xml"
缺點是要解除安裝必須要到本機群組原則編輯器裡面修改。
因為我還沒試過所以還不知道這個方法行不行，
有興趣而且也有適當網頁空間的人可以試一試。


u881831於 2014年2月22日星期六UTC+8下午5時27分43秒寫道：

u881831於 2014年1月17日星期五UTC+8上午2時20分05秒寫道：

PCMan於 2014年1月15日星期三UTC+8下午2時08分32秒寫道：

2014/1/12 u881831 <u88...@hotmail.com>

今年開始Google開始剔除NPAPI 的外掛程式了，

我這邊按照先前PCMan 的想法先弄一個packaged app處理socket，

加上自動啟動和隱藏UI後使用者體驗的部分算是可以接受了。

你太厲害了，我之前試驗一下弄不出來就沒弄了

居然真的被你做出來了!!!

剛試用過，相當棒！太厲害了！

BTW, 那個 about 頁面改一下吧，

其實現在大部份都是你做的了

把你自己的名字放前面吧，我的丟下面就好 :)

只是像這樣在GC的安全性機制打洞，

不只是上傳google play 可能會被刪除，

將來版本的GC會不會對這個動作設限也不知道。

我之前有私下 mail chrome developers 問相關問題

沒有獲得這方面的保證。

google play 的條款並沒有禁止這種應用

套件之間互相溝通，也是chrome 允許的合法機制，而非用 plugin 繞過

我倒是覺得可以上架看看，如果真的不允許，再來看怎麼弄

上架費用我可以負責出

我想這個版本應該能撐個一兩年吧。

如果撐不住，我還有想好三個備案

1. 開發 pepper API 為底的 plugin，專門提供 TCP socket 連線功能給 javascript。plugin 只做 socket 操作，這樣開發應該不難。

2. 用 node.js 寫一個小 proxy server，讓使用者另外下載安裝，跑在 localhost。於是，chrome 套件是連 http://localhost/， 然後由 server 轉用 raw socket 連外，兩者之間訊息用 json 互傳即可，都 js 寫起來應該很簡單。缺點是，server 接收到BBS站更新畫面，好像沒有好方法可以主動通知我們的 client? 如果用 websocket 而不是 http，這問題就沒了，但 node.js 弄 websocket 似乎比較麻煩？

3. 徵求善心人士提供一台 proxy server 讓我們連 http 轉 socket (例如某些學術網路)

 

1. PPAPI 外掛程式也會被 GC 的安全性限制影響，不能直接建立 socket 。
2. 網路上 node.js & websocket  應該有不少現成的程式，
   直接從那邊改的話應該不會太困難。
   只不過這個方法需要另外裝本機應用程式，
   這部分可能會讓部分使用者卻步。
3. 基於安全的理由，我想應該不會有網管會同意不特定的使用者進行不受限制的連線，（不限 IP 和 port ）
   而且基本上學網是不能架 open proxy 的。

我想等到真的被 GC 封鎖的時候應該是好幾年後了，
也許到時候還有其他新方法可以用。

除了從svn 下載外，封裝好的主程式可以從這邊下載：

https://drive.google.com/file/d/0B-K9h3GKW2VGZjBiNzE3ZmQtZGZkNi00MzAzLTk4NjktOTUxOTQ3ZGU1NGYz

處理socket的app 除了從svn 下載外，還可以從這邊下載：

https://drive.google.com/file/d/0B-K9h3GKW2VGb3dUdjlvRXBvcjQ

這個app 有白名單的設計，

白名單預設是空的所有套件都不能使用。

套件和app 都裝好之後，

第一次使用前請手動啟動app ，

出現設定視窗後請手動填入主程式的套件ID。

主程式的套件ID可以在GC的擴充功能設定頁找到。

技術上將填入套件ID的動作寫死在程式碼裡面是很容易，

不過目前這個套件還是處於開發中的狀態，

所以在安全性的考量下，

我就設計成必須手動填入名單，

這樣的話其他開發者應該可以直接把這個app 套用在他們修改過的程式，

另外像是ssh 等不同功用的套件應該也能直接用這個app 進行開發。

之後如果要上架，還是直接寫死比較安全，以免被濫用。

這樣似乎比較不會有安全上的疑慮

除此之外 socket app 這邊可能還需要一些調整，
目前的版本在 GC 升級重開的時候會自動 launch app ，
然後就彈出 app  的設定視窗。
我這邊有寫當所有 GC 瀏覽器視窗關閉時關閉 app，
似乎是因為 GC 關閉的過程是 non-blocking 的，
所以設定視窗還是會彈出來。
雖然可以暫時設定成 launch app 時不彈出視窗，
只是我覺得使用者手動 launch app 時至少出現一個視窗會比較好。

不過我最近比較忙，接下來可能要到春節才有時間處理了。

Google似乎開始緊縮擴充套件政策了：
https://sites.google.com/a/chromium.org/dev/developers/extensions-deployment-faq
目前我們這邊是使用者手動安裝，
不是弄一個可以自動更新的網址，
所以暫時沒有影響，
不過將來也許還是會被限制。

目前比較大的問題算是暫時解決了，
在socket.js 開頭填入PCMan 套件的ID就能直接綁定不讓使用者更改，
其他的像是整理程式碼之類的短時間內應該不會去弄，
也許我們可以開始考慮在Chrome Web Store上架了。
因為我之後可能沒有辦法繼續開發，
所以我沒有打算用我個人的帳號上架。
我想也許可以建立一個公用帳號，
不過因為我沒有將套件上架的經驗，
我不知道這樣做會不會出問題，
像是信用卡號設定等等，
這邊可能要大家一起討論後再決定。

然後看是要用什麼名子上架，
再將about 頁面改一下應該就可以上架了。
 

u881831於 2013年5月16日星期四UTC+8下午2時19分12秒寫道：

PCMan於 2013年4月11日星期四UTC+8下午1時14分56秒寫道：

我終於找到一個有趣的方法可以繞過 GC 的限制
透過 Chrome messaging APIs
這裡有範例
https://github.com/GoogleChrome/chrome-app-samples/tree/master/messaging
extension 和 packaged apps 之間可以互相呼叫
所以我可以把主程式放在 extension 內，
並且建立一個 helper app 專責處理 TCP connection
當 extension 開了新分頁，要建立連線時，
傳送一個訊息到 packaged app，由 app 進行 socket 操作，
然後把結果以 response 回傳給 extension
就可以完全繞過 GC 的限制，而且只用純 javascript
我有實際試過，這個方法是可以從 extension call app 內的 socket API
pcman 套件內呼叫 chrome.socket.* 的地方很少，
只要稍做封裝，把這幾個 calls 改成 messages 轉發到另一個 helper app
再從 helper app 內代為呼叫 chrome.socket 並且傳回結果給 extension
就可以實現了。而且剛好因為 socket API 都是 async 的方式，
和 messaging API 完全一樣，所以實現起來非常簡單。
基本上，只會用到 extension to app 單向的簡單訊息傳輸
如果有必要，甚至 helper app 也可以反向傳訊息呼叫 extension
例如要求 extension 開啟 new tab

唯一的缺點是，helper app 需要使用者手動執行，
因為新版 GC 已經取消 packaged app 的 background_page 了，
看起來必須手動啟動才行，好像不能從 extension 內呼叫起動?
any ideas?

如果需要手動執行helper app的話使用者體驗可能會很差，
而且為了處理多個BBS 分頁的情況，
程式架構會變得很複雜。

如果讓helper app藉由extension 的background_page 開啟瀏覽器分頁，
應該就不會有剛剛那些問題。
只是這樣做的話，
和現在的版本比起來就只有不用寫自己的分頁介面，
沒有辦法使用像是瀏覽器書籤之類的元件，（使用flash 的舊版本已經有這個功能）
和現有的版本比起來似乎沒有好上多少。
不知道大家有沒有什麼意見？


另外在FX版本上最近有一些變更，
首先在未啟用Direct2D的windows 電腦上，
FX 21 不再有ClearType (anti-aliasing) 效果。（影響範圍未確認）
應該只有較舊的電腦會受影響，
這邊應該不會去處理。

再來是Firegestures從1.7.1 起不會在xul 頁面的canvas元件上面作用，
https://github.com/gomita/firegestures/commit/14a6d0fdd4c44c198b16c8f07df5c3ea1e42689e
也就是說pref_test 這個branch的手勢功能必須在畫面邊緣才會啟動。
因為這邊不可能修改Firegestures的程式碼，
所以可能的處理方式就是把GC版本的獨立手勢功能移植回來，
不過目前GC版本的手勢功能還很陽春，
而且和其他手勢套件的衝突也是一個很麻煩的問題；
再不然就是把xul 介面改成html，
只是這樣要大改程式架構所以應該不會這麼做。
關於這部分不知道大家有沒有什麼意見？

 

2013/3/14 u881831 <u88...@hotmail.com>:
> 因為GC的限制只有做成獨立視窗才能使用socket api。
> 事實上不只是界面和瀏覽器主視窗分開，
> 獨立視窗和主視窗之間的資料傳遞也有很嚴格的限制。
> 我想應該是安全的考量吧，
> 一般網頁不可以進行不受限的TCP 連線。
>
> 我之所以會不想繼續開發這個版本也是因為這個限制。
> 另外如果要公開發布的話，
> 我想至少要有像pcman lite和pcmanx的分頁，
> 用html元件拼出分頁的界面其實不算太麻煩，
> 只是程式架構可能要大改才能同時進行多個連線，
> 我想我應該不會去處理這個部份。
>
>
> PCMan於 2013年3月14日星期四UTC+8下午12時39分34秒寫道：
>>
>> BTW, 我想問，
>> 有沒有什麼方法可以把那個BBS視窗塞到 chrome 的分頁裡面？
>> 在我這裡測試是自己獨立的視窗，這是刻意的嗎？
>>
>> 2013/3/14 PCMan <pcma...@gmail.com>:
>> > 非常感謝你的努力維護，
>> > 我本來發起這個專案，其實也是半實驗性質，
>> > 希望做為類似程式的參考，
>> > 事實上這幾年在醫院工作，我自己已經沒上BBS了，
>> > 不知道現在實際還在使用BBS的人口有多少？
>> > 但不管怎麼說，有一個這樣的專案展示 javascript 新技術，
>> > 還是很有意義的，所以還是很感謝你所做的開發.
>> > BTW, 我們要不要把你完成的 chrome 版，
>> > 公開發布出去？例如 web store?
>> >
>> >
>> > 2013/3/13 u881831 <u88...@hotmail.com>:
>> >>
>> >>
>> >> u881831於 2013年1月20日星期日UTC+8下午8時36分07秒寫道：
>> >>>
>> >>> GC 24 已經在幾天前出了，
>> >>> socket API已經包含在內，
>> >>> 而且不需要開實驗性擴充功能 API，
>> >>> 也就是說安裝完就能立刻使用了。
>> >>>
>> >>> 不過這個API 只能用在新的packaged app，
>> >>> 舊的（legacy packaged apps）除了不能用右上角的icon外基本上和extension 一樣，
>> >>> 不過新的packaged app和GC主介面是完全分開的，
>> >>> app 內的資源不能在GC主程式開啟，
>> >>> 而app 除了影音檔案外不能開啟外部網頁資源。
>> >>> 他們似乎是想防止比較危險的API 被主程式調用，
>> >>> 像是socket和直接存取本機硬碟的API 等等。
>> >>>
>> >>> 所以要用這個API 的話就不能使用GC的分頁和網址列，
>> >>> 想要使用分頁的話要用html元件自己組，
>> >>> 另外新的packaged app為了提升安全性和效能停用了一些API
>> >>> http://developer.chrome.com/apps/app_deprecated.html
>> >>> 有很多同步的API 不能用必須改用非同步的版本，
>> >>> 像是之前用來儲存偏好設定的localStorage就不能用了。
>> >>> 事實上新的packaged app還在發展中，
>> >>> http://developer.chrome.com/apps/api_index.html
>> >>> API 數量只有extension 的一半，
>> >>> http://developer.chrome.com/extensions/api_index.html
>> >>> 還有一些未解決的問題像是在擴充功能頁開啟偏好設定會出錯等等。
>> >>> （app 內資源只能在app window開啟）
>> >>> 將來可能會有更好用更強大的API 出現。
>> >>>
>> >>> 我這邊有先試著把pcmanfx GC版改成新的packaged app，
>> >>> https://docs.google.com/file/d/0B-K9h3GKW2VGbUJrWHJZSkVOTTQ/edit
>> >>> 主要是把同步的API 改成非同步的版本，
>> >>> app 一定需要的128*128 圖示我是從pcman novus 原始碼裡面的.ico轉的，
>> >>> 所以很抱歉app 做成桌面捷徑後圖示很模糊。
>> >>> 至於偏好設定那邊問題很大，
>> >>> 除了主介面因為上述的問題只能在右鍵選單開啟，
>> >>> localStorage要改成其他非同步API 造成整體架構需要大改，
>> >>> 目前的狀況是：
>> >>> 程式開啟時花0.5 秒等待偏好設定載入後再連線，
>> >>> 沒有observer所以每隔1 秒檢查設定是否變更，
>> >>> 也因為這樣我只有用一般的文字輸入欄位輸入網址，
>> >>> 沒辦法直接抓出站台列表並弄出快捷按鈕。
>> >>>
>> >> 最近將偏好設定系統做了一些調整，
>> >> 解決了上面提到的那些偏好設定系統產生的問題，
>> >> 這邊使用了GC 20+新增的datalist元件取代原來版本的Omnibox 網址列，
>> >> 和原來版本一樣可以自動補完站台的網址也可以列出站台列表。
>> >> 站台列表以前一樣會自動抓存在偏好設定內的站台。
>> >> 下載網址還是：
>> >> https://docs.google.com/file/d/0B-K9h3GKW2VGbUJrWHJZSkVOTTQ/edit
>> >>
>> >> 因為我不認為繼續開發這個版本有太大的意義，
>> >> 之後可能不會再維護。
>> >> 目前這個版本算是有把原有功能完全移植過去了，
>> >> 應該可以作為開發類似程式的參考。
>> >>
>> >>>
>> >>> 目前這個版本拖進擴充功能分頁之後就能直接用了，
>> >>> 不像先前使用flash 的版本除了需要安裝額外的外掛還有作一堆設定，
>> >>> 但是這個版本不能使用GC主程式的介面，
>> >>> 也不能直接開啟網頁，
>> >>> 從目前的API 來看這個版本再發展下去最多也只是另一個pcman lite或pcmanx，
>> >>> 除了跨平台外沒什麼繼續開發下去的意義。
>> >>> 圖示和一些deprecated API的修正我已經傳到SVN 了，
>> >>> 至於這個版本我先不上傳SVN ，
>> >>> 希望大家可以發表一下看法，
>> >>> 看看這個版本最後要怎樣。
>> >>>
>> >>>
>> >>> u881831於 2012年12月13日星期四UTC+8上午1時34分53秒寫道：
>> >>>>
>> >>>> 今天修正了兩個問題，
>> >>>> 修復不同分頁間包含ANSI彩色碼的複製貼上；
>> >>>> 還有Linux 下使用文泉驛字型時文字下方被切掉，
>> >>>> 微米黑的情況比正黑輕微。
>> >>>> 這次修正改用垂直置中的方式描繪文字，
>> >>>> 微米黑有在正中央但是正黑還是有一點偏高，
>> >>>> 比較正確的作法是量字高然後改變行高，
>> >>>> 因為會大量修改顯示模組所以暫時用置中的方式處理。
>> >>>> （附帶一提正黑的一些big5符號為全寬字而微米黑為半寬字，所以正黑的ANSI圖表現較好）
>> >>>>
>> >>>> 這邊稍微總結一下待辦事項：
>> >>>>
>> >>>>   socket api
>> >>>>   GC 24 stable釋出後再處理。
>> >>>>
>> >>>>   以下的部分比較重要但是工程浩大所以暫時不會處理：
>> >>>>
>> >>>>   registerProtocolHandler
>> >>>>   如果一直沒辦法實作的話，
>> >>>>   可能要把BBS 及GC一般網頁的所有telnet的超連結改成套件網址。
>> >>>>
>> >>>>   無法從網址列取得焦點
>> >>>>   可能要實作自己的網址列，
>> >>>>   在這個情況下把架構從套件改成APPS會比較好，
>> >>>>   另外改成APPS的話需要128*128 的icon。
>> >>>>
>> >>>>   右鍵選單項目藏在子選單內
>> >>>>   這邊可能也是需要用html元件實作出自己的選單，
>> >>>>   這樣也能解決Linux 下需要雙擊右鍵才能打開選單。（和手勢功能相衝)
>> >>>>
>> >>>>   以下是一些小問題也是暫時不會處理：
>> >>>>
>> >>>>   自訂手勢
>> >>>>   工程浩大....
>> >>>>
>> >>>>   訊息通知視窗不會自動消失
>> >>>>   可能需要實作自己的通知視窗，
>> >>>>   另外Linux 下如果要使用訊息通知音可能需要安裝TTS 聲音套件，像是
>> >>>>
>> >>>>
>> >>>> https://chrome.google.com/webstore/detail/us-english-female-text-to/pkidpnnapnfgjhfhkpmjpbckkbaodldb
>> >>>>
>> >>>>   加密自動登入的帳號密碼
>> >>>>   對telnet這種未加密連線而言沒有太大意義，
>> >>>>   因為目前沒有內建API ，
>> >>>>   自己實作加密的話意義不大。
>> >>>>
>> >>>>   列出GC內的搜尋引擎
>> >>>>   目前只有使用google搜尋BBS 內的關鍵字，
>> >>>>   不能使用縮網址還原之類的搜尋引擎，
>> >>>>   可能還是要另外實作自訂搜尋。
>> >>>>
>> >>>>   存取本機檔案系統的文件
>> >>>>   因為安全上的限制目前使用上下傳的方式存取本機文件，
>> >>>>   用起來很不方便，
>> >>>>   可能要等GC實作專供套件的API 。
>> >>>>   我覺得我們不應該使用繞過安全性限制的方法，
>> >>>>   將來那個方法被封住的可能性很高。
>> >>>>
>> >>>>   非同步的unicode 轉ansi相容編碼
>> >>>>   big5使用內建編碼表所以沒有這個問題，
>> >>>>   gb2312等其他編碼也只能看看之後有沒有想到更好的方法。
>> >>>>
>> >>>>   文字翻譯說明文件等等
>> >>>>   等到主要問題解決再處理。
>> >>>>
>> >>>>
>> >>>> u881831於 2012年11月30日星期五UTC+8上午2時05分34秒寫道：
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> u881831於 2012年10月30日星期二UTC+8上午12時03分54秒寫道：
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> u881831於 2012年10月26日星期五UTC+8下午9時50分43秒寫道：
>> >>>>>>>
>> >>>>>>> 前幾天我先寫出一個的GC版本的說明文件：
>> >>>>>>>
>> >>>>>>> http://u881831.blogspot.com/2012/10/bbs-addon-for-google-chrome.html
>> >>>>>>> 一般使用者只需要看最後一段的安裝方法就可以了。
>> >>>>>>>
>> >>>>>>> 關於GC版本的圖示，
>> >>>>>>> 目前16x16 的圖示檔我直接拿firefox 版的用，這邊應該沒有問題；
>> >>>>>>> 48x48 的我把PCMan novus 網站上的 logo.gif 轉成PNG 來用，之後也許會出問題；
>> >>>>>>> 128x128 的我沒有放所以套件安裝時的提示視窗就沒有套件的圖示。
>> >>>>>>> Google Chrome 對圖示的規定如下：
>> >>>>>>> https://developers.google.com/chrome/web-store/docs/images
>> >>>>>>> 不過我覺得暫時不需要遵守那邊的規定，
>> >>>>>>> 等以後有打算上架的時候再看看有沒有人要畫，
>> >>>>>>> 目前應該可以用類似這邊的圖檔：
>> >>>>>>> http://moon.cse.yzu.edu.tw/~s922254/pcman_icons/
>> >>>>>>> 不知道有沒有人有48x48 和128x128 大小的原始檔案？
>> >>>>>>>
>> >>>>>>> 另外關於偏好設定的程式碼，
>> >>>>>>> 因為FX內建API 不是很方便，
>> >>>>>>> 所以有一些地方的程式碼變得很冗長，
>> >>>>>>> 如果把整個架構重作，
>> >>>>>>> 像GC版本一樣用localstorage配合JSON儲存設定，
>> >>>>>>> 應該可以大幅簡化程式碼，
>> >>>>>>> 不知道大家有沒有什麼意見？
>> >>>>>>> 我可能會先實作在GC版本，
>> >>>>>>> 如果OK的話再弄到FX branch ，
>> >>>>>>> 最後 trunk 先整合偏好設定系統，
>> >>>>>>> 已實作偏好設定就再說。
>> >>>>>>>
>> >>>>>>>
>> >>>>>> 似乎大家沒有意願改掉Content Preference的偏好設定系統，
>> >>>>>> 我這邊先維持原技術只重構程式碼：
>> >>>>>> 在主程式和設定介面裡面，
>> >>>>>> 偏好設定的細節部分交給偏好設定的核心處理；
>> >>>>>> 把使用Content Preference API的部分獨立出來，
>> >>>>>> nsILoginManager 的部分也獨立出來，
>> >>>>>> 這樣偏好設定的核心部分就可以FX和GC共用；
>> >>>>>> 和設定介面元件的互動程式碼也獨立出來，
>> >>>>>> 其他的部分基本上可以跨瀏覽器共用。
>> >>>>>> 至於站台管理的部分新增了一些功能：
>> >>>>>> 現在可以在設定介面直接新增任意的站台，
>> >>>>>> 也能刪除預設站台，（實際上是將預設站台的設定重設回預設值）
>> >>>>>> 核心內部也實作了把從站台A 的設定複製到站台B ，
>> >>>>>> 不過使用者介面的部分還沒實作複製的按鈕。
>> >>>>>>
>> >>>>>> 除了偏好設定系統，
>> >>>>>> 也有一些部分需要重構才能做到跨瀏覽器共用，
>> >>>>>> 不過我短時間內應該還不會去處理。
>> >>>>>>
>> >>>>>> P.S. FX的舊站台設定不相容於新版，
>> >>>>>> 請備份之後再升級，
>> >>>>>> 升級後請移除站台列表中所有站台再新增。
>> >>>>>>
>> >>>>>>
>> >>>>>>>
>> >>>>>>> PCMan於 2012年10月9日星期二UTC+8下午10時23分58秒寫道：
>> >>>>>>>>
>> >>>>>>>> 2012/10/9 u881831 <u88...@hotmail.com>:
>> >>>>>>>> >> PCMan於 2012年10月3日星期三UTC+8上午11時58分46秒寫道：
>> >>>>>>>> >>>
>> >>>>>>>> >>> 2012/10/2 u881831 <u88...@hotmail.com>:
>> >>>>>>>> >>> > socket API看起來應該可以替代現有的flash 連線，
>> >>>>>>>> >>> > 雖然標experimental的API 依然需要使用者作一些設定才能用，
>> >>>>>>>> >>> > 不過跟現在的flash 相比還是好很多，
>> >>>>>>>> >>> > 而且這個API 將來也有可能去掉experimental標籤。
>> >>>>>>>> >>>
>> >>>>>>>> >>> 我也覺得很有可能，都已經給這麼多範例了，還有人開始在利用這個做 extension
>> >>>>>>>> >>> 但是他的使用方法和 Fx 的差異不小，可能我們需要包裝一下
>> >>>>>>>> >>> 弄一個我們自己的 socket class，把 Fx 和 GC 的差異封裝起來
>> >>>>>>>> >>>
>> >>>>>>>> >>> > 不過我想還是等這個API 進stable channel後再來實作會比較好。（似乎是GC23）
>> >>>>>>>> >
>> >>>>>>>> > 周末的時候試了一下，
>> >>>>>>>> > GC23雖然可以認出manifest裡面的socket的權限，
>> >>>>>>>> > 但是因為這個API 限定dev channel 才能使用所以無法執行，
>> >>>>>>>> > 看來到stable channel能用為止還有得等。
>> >>>>>>>>
>> >>>>>>>> 對，但至少未來當 flash 完全不能用的時候，socket API 應該已經成熟
>> >>>>>>>>
>> >>>>>>>> > 另外這個文件似乎還沒跟上程式碼的變化：
>> >>>>>>>> > https://developer.chrome.com/apps/app_network.html#connecting
>> >>>>>>>> > 這邊有該文件Reviewer的意見：
>> >>>>>>>> > https://chromiumcodereview.appspot.com/10908045
>> >>>>>>>> >
>> >>>>>>>> > 也就是說UDP 範例程式碼所使用的onEvent 似乎已經被棄用，
>> >>>>>>>> > https://chromiumcodereview.appspot.com/10273016
>> >>>>>>>> > 目前看到的範例套件都沒有使用這個功能，
>> >>>>>>>> > 所以我們可能需要想一想FX內監聽socket事件的函式要怎麼移植。
>> >>>>>>>> >
>> >>>>>>>> > 我直接執行範例套件得到一些初步的結論：
>> >>>>>>>> >
>> >>>>>>>> > onStartRequest
>> >>>>>>>> > 應該可以直接由連線的callback函式確認result >= 0 後直接呼叫。
>> >>>>>>>> >
>> >>>>>>>> > onDataAvailable
>> >>>>>>>> > 只能用setInterval 或是其他方法不斷的呼叫read，
>> >>>>>>>> > 當有資料時再呼叫這個函式。
>> >>>>>>>> > 這部分對程式效能有非常重大的影響，
>> >>>>>>>> > 間隔太長的話反應很慢，
>> >>>>>>>> > 太短的話主程式呼叫函式次數太多可能會拖慢速度，
>> >>>>>>>> > 可能要仔細想一想要怎麼做。
>> >>>>>>>>
>> >>>>>>>> 這個不會很困難，當 socket.connect() 之後，在 connect Callback 裡面，
>> >>>>>>>> 呼叫 readNext(); // 在下面定義
>> >>>>>>>>
>> >>>>>>>> function readNext() {
>> >>>>>>>>     socket.recv(id, 4096, readCallback);
>> >>>>>>>> }
>> >>>>>>>>
>> >>>>>>>> 然後定義
>> >>>>>>>> function readCallback(readInfo) {
>> >>>>>>>>     if(readInfo.resultCode > 0) {
>> >>>>>>>>         onDataAvailable(readInfo.data);
>> >>>>>>>>         setTimeout(0, "readNext()"); // 利用 setTimeout 0 秒
>> >>>>>>>>     }
>> >>>>>>>> }
>> >>>>>>>>
>> >>>>>>>> 這樣就可以了，不需要 setInterval()。
>> >>>>>>>> 每次讀取完一次資料，就再讀下一次，直到 resultCode = -15，就斷線。
>> >>>>>>>> 如此可以簡單模擬出原來的架構，而且效能搞不好不差？
>> >>>>>>>> 可以試試看
>> >>>>>>>>
>> >>>>>>>> > onStopRequest
>> >>>>>>>> > 根據socket API的文件，
>> >>>>>>>> > 我們只能從read和write 的回傳狀態碼得知是否已斷線，
>> >>>>>>>> > 要是已經斷線的話WriteInfo 會是{bytesWritten: -15} ，
>> >>>>>>>> > ReadInfo是{data: ArrayBuffer, resultCode: -15}，
>> >>>>>>>> > 至於連線中而且沒有新資料的時候resultCode是-1。
>> >>>>>>>> > 同樣的這個也需要不斷的呼叫read或write 。
>> >>>>>>>> >
>> >>>>>>>> > 總而言之，以目前API 的功能應該可以取代原有的flash socket，
>> >>>>>>>> > 但是目前這個API 似乎還沒成熟，
>> >>>>>>>> > 也許之後resultCode會變動或是出現更好的監聽socket事件的方法。
>> >>>>>>>> > 我覺得至少要到stable channel能夠使用後再實作比較有意義，
>> >>>>>>>> > 現在實作的話有可能會碰到API 改變而需要大幅改寫程式碼的情況。
>> >>>>>>>> > 不過要是有人想要先試試看的話，
>> >>>>>>>> > 應該可以由官方範例以及這邊提供的資訊做出完整的功能。
>> >>>>>>>> >
>> >>>>>>>> >>>
>> >>>>>>>> >>> >
>> >>>>>>>> >>> > 目前使用Flash 實作的功能除了socket外還有編碼轉換，
>> >>>>>>>> >>> > 雖然編碼轉換的功能應該可以直接用內建的PPAPI flash ，
>> >>>>>>>> >>> > 不過flash 內似乎也沒有直接的轉換API ，
>> >>>>>>>> >>> > 轉換的功能也是用數個API 組合出來，
>> >>>>>>>> >>> > 再加上flash 和javascript之間的資料傳遞，
>> >>>>>>>> >>> > 所以目前的編碼轉換很慢。
>> >>>>>>>> >>>
>> >>>>>>>> >>> 你要轉換什麼編碼？如果是 big5 to Unicode, 我記得我們有寫過啊？
>> >>>>>>>> >>> 那個 unicode 補完支援，不就有對照表可以查？
>> >>>>>>>> >>> Firefox 裡面用 js 實做不會很慢喔，GC 應該只會更快
>> >>>>>>>> >>> 需要的話我可以來做這塊。
>> >>>>>>>> >>> 還是你講的是不一樣的東西？
>> >>>>>>>> >>
>> >>>>>>>> >> 我弄這邊的目的主要是轉換gb等非big5編碼，
>> >>>>>>>> >> 目前的套件已經實作了這個功能。
>> >>>>>>>> >> 所以我在想有沒有辦法完全捨棄flash 但是保留現有的功能，
>> >>>>>>>> >> 如果使用純HTML的話我想應該會有效能的提升吧。
>> >>>>>>>> >>
>> >>>>>>>> >> 目前我試出的方法最大的問題是unicode 轉Big5的函式是asynchronous，
>> >>>>>>>> >> 不過套件裡有用到u2b 的就貼上彩色文字以及純文字貼上鍵盤輸入兩個地方，
>> >>>>>>>> >> 都是要往socket送資料，
>> >>>>>>>> >> 這個動作本來就是asynchronous。
>> >>>>>>>> >> 因為我之前有做編碼轉換結果的緩存，
>> >>>>>>>> >> 所以當緩存裡面找不到的時候進行asynchronous轉換並終止函式，
>> >>>>>>>> >> 每隔一小段時間重送，
>> >>>>>>>> >> 等到轉換結果進緩存再將資料送到socket就可以了。
>> >>>>>>>> >> 也就是說即使使用asynchronous u2b轉換也不需要大改程式架構，
>> >>>>>>>> >> 不過如果可以用synchronous 轉換的話程式架構會比較簡潔易讀。
>> >>>>>>>> >>
>> >>>>>>>> >> 至於Big5的話因為要支援UAO 所以一定要內建編碼表，
>> >>>>>>>> >> 所以就不需要考慮這些問題，
>> >>>>>>>> >> UTF8編碼的話單就轉換而言很容易只是termbuf 架構要改。
>> >>>>>>>> >>
>> >>>>>>>> >>> > 我這邊有想到用HTML本身的API 組合出編碼轉換的方法，
>> >>>>>>>> >>> > 不過速度上可能不會比現在快。
>> >>>>>>>> >>> > 不知道大家有沒有更好的方法？
>> >>>>>>>> >>> > 還是沿用現有的flash API ？
>> >>>>>>>> >>> >
>> >>>>>>>> >>> > 除了上面這些，目前還有一些待改善的問題，
>> >>>>>>>> >>> > 在支援GC本身書籤後我之前做的下拉選單就沒有存在必要了；
>> >>>>>>>> >>> > registerProtocolHandler 沒有進展而omnibox keyword 有很多問題，
>> >>>>>>>> >>> > 弄成APP 然後在web 頁面用html元件拼出自己的網址列，
>> >>>>>>>> >>> > 也許會有比較好的使用者體驗？
>> >>>>>>>> >>>
>> >>>>>>>> >>> 這也是一個選項，先求功能正確，再求完美整合啊
>> >>>>>>>> >>>
>> >>>>>>>> >>> > 右鍵選單似乎只能控制個別套件的子選單，
>> >>>>>>>> >>> > 而且那個API 的目的似乎是要服務所有HTML頁面，
>> >>>>>>>> >>> > 就我們的需求而言，
>> >>>>>>>> >>> > 似乎禁用原有選單然後用HTML元件拼出右鍵選單才是比較正確的做法？
>> >>>>>>>> >>>
>> >>>>>>>> >>> 同意，而且我們應該不太需要原本右鍵選單裡面的功能。
>> >>>>>>>> >>>
>> >>>>>>>> >>> > 還有一些比較不重要的問題：
>> >>>>>>>> >>> > 右鍵搜尋的部分我還找不到API 來實作；
>> >>>>>>>> >>> > 訊息通知音目前使用tts 實作，但是Linux 下沒有tts 可以用，
>> >>>>>>>> >>> > 其他類似軟體都是用在extension內放mp3 等檔案，
>> >>>>>>>> >>> > 也許我們可以把開放版權的聲音檔案包進這個套件？
>> >>>>>>>> >>> 這是很合理的作法，聲音檔案去 pidgin / libpurple 裡面抓現成的就好了，
>> >>>>>>>> >>> 很容易解決
>> >>>>>>>> >>>
>> >>>>>>>> >>> > 自動登入的帳號密碼目前也還沒找到比較安全的儲存方法。
>> >>>>>>>> >>> 個人覺得不需要，在畫面上寫清楚是明碼儲存就好了。
>> >>>>>>>> >>> telnet 本來就是毫無安全性的東西，密碼輸入也是以明碼送出到網路，
>> >>>>>>>> >>> 有心人要竊取非常容易。
>> >>>>>>>> >>> 再者，如果有人可以進你的電腦，開啟你的設定檔來看密碼，
>> >>>>>>>> >>> 那他還有什麼其他不能做的事？甚至可以裝 key snooper，
>> >>>>>>>> >>> 看 BBS 密碼算小事了。
>> >>>>>>>> >>
>> >>>>>>>> >> 附帶一提我之前提到的右鍵搜尋是指列出GC內建的所有搜尋引擎，
>> >>>>>>>> >> 然後將選取的文字用選中的搜尋引擎搜尋，
>> >>>>>>>> >> 目前GC內建的搜尋引擎除了Google自己外還有Yahoo!和Bing，
>> >>>>>>>> >> 而目前的套件只是開一個新分頁而已：
>> >>>>>>>> >> http://www.google.com/search?q=%s
>> >>>>>>>> >> 沒有辦法抓取其他搜尋引擎。
>> >>>>>>>> >>
>> >>>>>>>> >>> > 下面是剛剛提到純HTML的編碼轉換：
>> >>>>>>>> >>>
>> >>>>>>>> >>> > big5char.htm
>> >>>>>>>> >>> >
>> >>>>>>>> >>> > <html>
>> >>>>>>>> >>> > <head>
>> >>>>>>>> >>> > <meta http-equiv="Content-Type" content="text/html;
>> >>>>>>>> >>> > charset=utf-8"/>
>> >>>>>>>> >>> > <script type="text/javascript" src="big5char.js"></script>
>> >>>>>>>> >>> > <title>Big5 code converter</title>
>> >>>>>>>> >>> > </head>
>> >>>>>>>> >>> > <body>
>> >>>>>>>> >>> > <!-- Necessary elements for u2b api -->
>> >>>>>>>> >>> > <form id="u2b_form" action="u2b.htm" target="u2b_frame"
>> >>>>>>>> >>> > accept-charset="big5">
>> >>>>>>>> >>> >  <input type="hidden" id="u2b_ustr" name="u2b_ustr">
>> >>>>>>>> >>> > </form>
>> >>>>>>

...

--

---
這是 Google 網上論壇針對「pcmanfx」群組發送的訂閱通知郵件。
如要取消訂閱這個群組並停止接收來自這個群組的郵件，請傳送電子郵件到 pcmanfx+u...@googlegroups.com。
如需更多選項，請前往：https://groups.google.com/d/optout。

--
Ett Chung

[PCMan]

2014-06-30 22:56 GMT+08:00 u881831 <u88...@hotmail.com>:
> Windows 下 Google Chrome 35以後非商店的擴充套件都被封鎖了，
> 目前暫時的解決方案有兩個，
> 一個是用開發者模式載入擴充套件；
> 另一個是用群組原則強制安裝套件，
> 事實上設定群組原則的方法沒有很複雜，
> 從Google下載範本後，
> 直接在群組原則設定介面填入套件ID就好了。
> 對這兩個方法的細節有興趣的可以看：
> http://u881831.blogspot.tw/
> 詳細步驟在那個頁面的最後一段。
>
> 正規的方法除了在商店上架之外，

我之前有看了一下，不曉得要怎麼弄
如果你能把他上架的話，要付錢給 Google 我可以出

> 還有把擴充套件改成Apps，
> 之前我有寫過，
> 因為這種架構只能開在獨立的視窗，
> 不能開在瀏覽器分頁裡面，
> 所以這種架構的版本暫時擱置；

做這個最主要的目的就是要在瀏覽器分頁裡面用
變成獨立 app 就沒意思了，不如另外開發

> https://drive.google.com/file/d/0B-K9h3GKW2VGbUJrWHJZSkVOTTQ
> 另外就是把擴充套件改成一般網頁，
> 這樣一來除了message passing API 以外的擴充套件API 都不能用了，
> https://developer.chrome.com/apps/messaging#external-webpage
> 有些功能必須要將程式碼整段重構，
> 甚至有些功能完全不能使用。

如果網路傳輸部份改用外部 proxy server (node.js)
那這並不是不可行，因為網頁不能使用的功能
可以以 node.js 寫 local server 提供 RESTful API 解決，搞不好還更簡單

> 之前 PCMan有提幾個備用方案，
> 其中一個是用node.js 在客戶端架伺服器，

我覺得 local server 比較容易，而且比較安全
外部 server 會有容易被監聽的疑慮，而且沒人提供這個 server

> 再不然就是在外面另外找一個伺服器。
> 這次出問題的是主程式而不是socket連線，
> 不過還是可以用這兩個方法建立一般網頁架構的主程式。
> 使用外部網頁伺服器的話除了不能在內部網路使用外，
> 也有伺服器或是網路掛掉的風險。
> 如果要在客戶端架簡單的網頁伺服器的話，
> 因為GC的socket api支援伺服器端連線，
> 而且Google有提供簡單的範例，
> https://github.com/GoogleChrome/chrome-app-samples/tree/master/webserver
> 所以我就用這個範例建立新的架構。
>
> 首先我先將這個範例裡面的socket api改成新版的，（GC 33 起支援）
> 我原來的socket agent也改用新版的api 並整合到這個範例裡面。
> 新版的api 可以監聽onReceive 事件，
> 不用自己寫迴圈read socket ，
> 執行效能有很大的改進。
> 然後我把伺服器的DocumentRoot改到套件裡面，
> 這樣所有程式碼就包在一個單一的.crx裡面，
> 使用者安裝的步驟就更簡單了。
> 下面是我初步的成果：
> https://drive.google.com/file/d/0B-K9h3GKW2VGUG92TlB2QUV4Uk0

你真的是非常強大，這些我有的已經看不太懂了!!!
我目前有一個想法，可以跑得動 Chrome 和 firefox 的電腦
基本上硬體設備不可能會差，所以犧牲一點點效率沒關係，硬碟空間也沒問題
可以把整個 telnet client 搬出 browser 外，不要做 extension
改成跑在 local web server，可用 node.js 寫 (用 websocket 更合適)
這樣可以同時支援所有 browser!!! IE, firefox, chrome, safari, opera 全部可用
使用上只要在瀏覽器連到 http://localhost:5678?host=ptt.cc&port=23 (5678 為我們自己
server 的 port，我隨便取的)
連線的時候就會轉到跑在 local 端的 node.js web server，
由 local web server 來轉連到 telnet server，然後動態產生網頁內容
缺點是這個 server 需要常駐 (以現在的硬體來說是小菜一碟)
但是很大的優點是，可以支援全部的 browser
而且不用針對不同 browser 的 extension 寫不同 code，維護上好很多
未來更新也只要安裝新版 server，不用個別瀏覽器升級套件/plugin
需要跟本機檔案互動，存取資源，可以都用 node.js 操作，事情會比現在單純很多
至於 config 的 UI，可以用 jqueryUI 或其他的 js UI library 就搞定了
也不用寫 XUL 或是其他 chrome specific 的 code
的確是一個可以考慮的方案
如果真的需要和特定瀏覽器整合，只要寫一個 thin wrapper app
用一個很簡單的 extension 導向 http://localhost 即可
像 firefox extension 就只需要做收到 telnet:// 的 URL，就 redirect 到 http://localhost
其他功能幾乎都不必寫了... (都搬到 server 裡面了)

[u881831]

PCMan於 2014年7月1日星期二UTC+8上午10時16分43秒寫道：

我把程式碼重新整理並打包成新版了，（沒有新增的功能）
不過程式碼可讀性應該還是比不上Node.js 寫出來的server，
因為我這邊必須自己處理HTTP傳輸的細節。

我想改用Node.js 最麻煩的地方就是教一般使用者如何安裝使用，
我覺得應該不可能會比安裝瀏覽器及擴充套件簡單，
而且跨平台的安裝設定應該都不一樣。
不過也許有人知道怎樣解決這個問題。

我想對不用GC的使用者而言，
應該也是可以安裝GC當作應用程式的執行環境。
因為Google也有提供websocket server的範例，
而且不像我用的web server範例那樣過度陽春，
也許可以不用花太多時間修改。
我想這樣的話不但可以跨瀏覽器，
將來如果要改用Node.js 的話也不用再改主程式。

[PCMan]

Also see this, please.
http://free.com.tw/pttchrome/
Looks interesting!

[u881831]

PttChrome 用message passing API 讓應用程式和一般網頁通訊，
藉以解決擴充套件被禁用的問題。
他的應用程式放在Google商店而網頁放在一個外部伺服器裡面，
使用者的安裝使用相當方便，
我目前的測試版也是有受到PttChrome 的啟發，
不過這種做法也有這種做法的問題。

這幾天我從這個範例取出並修改伺服器模組並整合到我的測試版中。
https://github.com/GoogleChrome/chrome-app-samples/tree/master/websocket-server
用websocket 取代message passing API 後，
連IE和FX都可以透過這個應用程式連線，
雖然說用非GC瀏覽器連線的話仍然有一些小功能不相容，
IE和FX都不能背景開啟新分頁，
FX顯示連線狀態的圖示不會更新，
IE沒有辦法更改字型所以直接綁定細明體。
至於安裝連線方法和前一版一樣：
https://drive.google.com/file/d/0B-K9h3GKW2VGUG92TlB2QUV4Uk0
IE系統需求是版本10以上，
雖然我只在GC35 FX30 IE11(Win8.1)上面測試過，
不過我想在Trident Gecko Webkit(Blink) 這幾種主要瀏覽器引擎上都能用的話，
用其他類似核心的瀏覽器應該不會出太大的問題。

目前這個版本的效能應該還比不上之前用message passing API 的版本。
因為websocket 技術有單向的加密，
而且目前版本的websocket 伺服器只支援一般字串模式傳輸，
不支援binary字串，
所以這個版本在做資料交換時還要做base64編解碼。
如果將來我有找到支援binary資料的伺服器端實作範例的話，
我再把這個功能加上去。

程式架構方面，
websocket server範例的作者把伺服器模組的API 設計成和Node.js 的一樣，
然後我也把telnet連線的部分模組化，
所以直接看主程式就能了解整個伺服器端的運作。
而且主程式這邊的程式碼和使用Node.js 的非常類似，
將來如果要改用Node.js 的話應該也可以很輕鬆地移植。

另外原本的範例有讓外部連到這個伺服器的功能，
不過這幾個測試版本因為安全性的考量只開放本機連線。
原版的使用者介面會把本機所有的網路介面列出來，
使用者可以直接挑選要監聽的網路介面。
如果不改介面要直接修改程式碼的話，
把listen的address 改成聯外的網路位址或是0.0.0.0 就可以監聽外部連線。

因為我沒有對伺服器模組的API 做大幅修改，
所以可以直接將我改過的http.js 放回原來專案中。
（還有要在manifest.json 新增新版socket API需要的權限）
如果有人想要更了解websocket 伺服器運作的話，
這樣應該會更方便。


PCMan於 2014年7月2日星期三UTC+8上午12時36分56秒寫道：

[u881831]

0.0.6.3版本實作出websocket的二進位資料傳輸了，
雖然這個版本只支援arraybuffer 不支援blob，
不過應該已經夠用了。
效能方面因為少了base64和UTF8編解碼應該快了一點，
另外HTTP模組內部應該可以針對二進位資料傳輸做效能的優化，
不過因為要大量修改程式碼所以暫時擱置。
https://drive.google.com/file/d/0B-K9h3GKW2VGUG92TlB2QUV4Uk0

另外這個app 應該可以移植回Firefox ，
如果是Extensions架構的話，
所有的功能應該都能實作出來，
只是每次要用都要開瀏覽器視窗。
Mozilla 也有為Firefox OS開發出open web apps 架構，
桌面板Firefox 29+ 開始支援這種架構，
可以和瀏覽器視窗獨立運作。
這種架構也和GC一樣支援packaged apps 和hosted apps。
而且這個架構和GC的apps 很像移植應該不會太困難，
應該可以當作GC禁用非商店apps時的備案。

另外這個架構可能還不是很穩定，
目前應該可以建立socket進行連接或監聽，
至於其他功能的實作應該問題不大，
只是處理複製貼上的API 似乎有點問題，
將來的版本才會解決。

不知道大家對open web apps 架構或是程式本身有什麼看法？


u881831於 2014年7月4日星期五UTC+8下午10時48分05秒寫道：

&gt

...

[u881831]

今天弄出了0.0.6.4 版本，
新增背景執行的選項，
而且也修掉一些小問題。（主要是瀏覽器辨識的問題）
https://drive.google.com/file/d/0B-K9h3GKW2VGUG92TlB2QUV4Uk0

這次新增的背景執行功能只影響app 在launch時的行為，
未啟動這個功能時，
初次launch會建立新視窗，
之後的launch就只是把視窗從最小化回復；
啟動背景執行功能後，
初次launch時除了會把新增的視窗藏起來，
還會自動啟動伺服器，
之後的launch會顯示隱藏的視窗或把視窗從最小化回復。
有了這個功能之後，
應該就能搭配系統服務設定全自動啟動，
http://www.chromium.org/developers/how-tos/run-chromium-with-flags
http://peter.sh/experiments/chromium-command-line-switches/#app-id
至於詳細步驟的話各個作業系統都不一樣，
這邊就不詳細說明了。
附帶一提如果使用者沒有在關閉瀏覽器前先斷線的習慣的話，
請先叫出app 的視窗，
然後按下Stop再關閉視窗；
如果已經沒有任何連線，
可以直接關掉這個app 的process 。

這是因為GC視窗的關閉是非同步的，
以我目前的架構onClosed未必能正常工作。
app 架構的設計理念是可以隨時關閉開啟，
必要的data存放在local storage 之類的地方，
下次開啟時再載入。
以客戶端連線程式為例，
當程式建立socket時就把socket id 放到local storage 裡面，
（當然想要隨時關閉開啟的話還要放很多東西，這邊只討論正常關閉）
當app 視窗關閉時背景頁面的onClosed事件處理函式開始執行，
從local storage 取出未斷線socket的id並執行斷線，
這個流程完全不會出問題。
至於伺服器的部分，
HTTP伺服器可以照上面的流程直接斷線，
websocket伺服器的話根據w3c 規範斷線前要做一些動作，
不過直接斷線的話也不會有太大的問題。
只是那種架構寫起來很麻煩，
而且app 架構中的local storage api 是非同步的，
所以我就沒有為了正常關閉這種小問題寫成那種架構。

至於啟動的部分，
因為之前的0.0.5.* 是綁GC瀏覽器的app ，
所以這個app 就設計成會在GC瀏覽器視窗啟動時一起啟動，
然後隨著GC瀏覽器視窗的關閉而關閉，
不會佔據多餘的系統資源。
只是有些使用者會把起始畫面設定為繼續瀏覽上次開啟的網頁，
也就是會在開啟GC時同時執行BBS 分頁和載入app ，
因為GC的啟動流程是非同步的，
不一定會照順序執行載入app 和連接BBS 伺服器，
要是順序反過來就會連線失敗。
基本上像這種偶爾才出現的問題很難除錯，
所以當時沒有徹底解決。

在GC禁用非商店擴充套件後，
基本上已經沒有辦法偵測GC瀏覽器視窗的關閉，
再加上現在的架構也能讓其他瀏覽器連線，
不可能只偵測GC瀏覽器視窗，
為了避免浪費系統資源，
所以這邊決定讓使用者自行判斷開啟關閉的時機。
現在我想不出其他跨平台的解法，
如果沒有人提出其他方法的話，
這個程式的架構就這樣定下來了。
不知道大家有什麼想法？


u881831於 2014年7月8日星期二UTC+8下午11時30分15秒寫道：

...

[PCMan]

試用過了，非常順暢！
我只能說你實在是太強了
這比原來的用 message api 要乾淨多了
只是使用方式比較不直觀
我搞不太懂要怎麼把這玩意上架到 google
如果你會弄的話可以拜託你嗎？
上架所需費用我可以全出
Thanks!

[u881831]

這幾天弄出了0.0.6.5版本，
新增了簡單的右鍵選單，
以及偏好設定頁面；
另外修正了HTTP模組在有querystring 時無法判斷 MIME type，
以及網頁子目錄下不會載入DirectoryIndex頁面。
https://drive.google.com/file/d/0B-K9h3GKW2VGUG92TlB2QUV4Uk0

右鍵選單的部分，
在以前GC版的架構下BBS 頁面無法使用其他的滑鼠手勢套件，
不過在現在的架構下BBS 頁面就只是一般網頁，
可以使用其他的滑鼠手勢套件，
要是弄一個自己的右鍵選單，
可能會讓滑鼠手勢套件無法正常工作，
所以之前還在考慮要不要實作。
不過使用熱鍵的方式不夠直觀，
所以暫時先寫一個簡單的右鍵選單出來。

偏好設定的部分，
核心模組基本上就是之前版本的程式碼做一些小修改，
而目前的可以設定的只有編碼。
之前版本在非big5編碼下會一直向瀏覽器查詢編碼表，
而查詢的方法是XMLHttpRequest的overrideMimeType和HTML <form> 的accept-charset，
這兩個動作都很慢，
所以瀏覽非big5編碼的BBS 時會覺得很鈍。
現在的版本雖然還是用這兩種方法，（目前我也不知道其他比較好的方法）
不過會在載入頁面時直接查詢整個編碼表，
所以瀏覽非big5編碼的BBS 應該會和瀏覽big5編碼的BBS 一樣順。
至於載入頁面時的延遲，
在比較好的電腦上應該不會超過一秒，
應該還算是可以接受。

至於啟動和關閉這個App 的動作還是沒有比較方便的辦法，
啟動的話可以要自行註冊成系統服務或是手動開啟，
關閉的話就只能手動關閉。
等到這個功能實作完成，
https://code.google.com/p/chromium/issues/detail?id=165573
應該才有辦法把啟動和關閉的流程弄得比較方便。
目前是有一個workaround，
http://stackoverflow.com/questions/19227472/how-to-open-a-chrome-packaged-app-with-a-parameter-on-windows
只是這樣弄的話流程也還是很繁複。

另外，要上架的話是我最近弄的這個版本上架？
之前的擴充套件版本雖然不能和其他擴充套件互動，
但是能實作的功能比較完整。
最完美的方法應該是像PttChrome一樣多弄一個擴充套件出來：
https://chrome.google.com/webstore/detail/web2pttchrome/pjemnpgdmnlkkcpaddlnlegmdfpohnep
這樣應該可以把之前右上角的icon和omnibox 關鍵字弄回來，
只是這樣就幾乎等於把瀏覽器介面互動的模組整個重寫了。


PCMan於 2014年7月10日星期四UTC+8下午3時21分41秒寫道：

[u881831]

最近Google宣布即將在桌面板Chrome棄用Chrome apps 架構，
最快一年半之後pcman-chrome和所有使用Chrome apps 的BBS 程式都將無法使用。
Google建議現有的apps可以轉成下列架構：
1. HTML5 架構的web app：（跨瀏覽器）
   沒有建立raw socket的方法。
2. 使用extensions架構：（限GC）
   現階段也沒有建立raw socket的方法，
   開發者可以建議將某些Chrome apps API 移植到Chrome extensions API ，
   不知道將來sockets.tcp會不會移植。
3. 使用Electron或NW.js 建立native app：
   只有HTML5 API 和瀏覽器相關，
   所以應該不會因為瀏覽器改版又要更改架構。
   只是可能需要在各平台進行封裝測試（不熟不確定）

如果要將pcman-chrome的app 改成native app的話，
現有app 的http server/websocket server/socket creater 功能應該只能用native app實作，
其他的功能主要有big5以外編碼的轉換和複製貼上，
html5 的big5以外編碼轉換可以整合這個project 的library ，
轉換速度應該也會變快；
html5 的複製貼上應該只能做到像Google drive一樣，
只能用快捷鍵複製貼上，
勉強還算堪用。
另外也許可以考慮讓這個native app可以不依靠瀏覽器直接顯示畫面，
只是定位上會和其他project 重疊。


u881831於 2014年7月17日星期四 UTC+8下午10時38分13秒寫道：

[WM]

是的，定位上就會跟 plasmon 重疊。

至於複製貼上的問題，在 plasmon 中是使用了 Electron 提供的 API 來繪製出右鍵選單以及操作剪貼簿。

u881831於 2016年9月15日星期四 UTC+8下午10時32分55秒寫道：

[u881831]

因為 NW.js 平台原生支援 Chrome apps 架構並且不打算捨棄這個架構，
我先對 pcman-chrome 做一些小調整讓這個 app 用 NW.js 運行時不會有功能缺損，
BBS 分頁就開在任何一個支援 HTML5 的瀏覽器，
這樣的話短時間內至少還有一個備案能用。
接下來看看之後 Google Chrome extensions 會不會有建立 raw socket 的方法，
畢竟完全使用瀏覽器內部功能的話架構比較簡潔。
另外使用 Google Chrome extensions 直接存取本機應用程式也是一個可能的方案，
安裝完後的使用者體驗應該可以和 PttChrome 差不多，
只是安裝設定本機應用程式相當麻煩。

如果之後 Google Chrome extensions 還是沒有建立 raw socket 的方法的話，
因為 Chrome apps 架構的使用者預期會愈來愈少，
NW.js 將來還是有可能棄用這個架構，
最後可能還是要移植到 Electron 等平台。
這部分需要更改原有 app 架構進行移植，
短時間內應該不會進行。

附帶一提從今年底的 Firefox 57 開始將只支援 WebExtensions，
舊有的 BBS 擴充套件將完全不能用，
不過 WebExtensions 還不能建立 raw socket，
還不能進行移植。
要是這個功能來不及在今年底完成的話，
可能短時間內也要用 NW.js 的備案。


WM於 2016年11月13日星期日 UTC+8下午11時37分43秒寫道：

[u881831]

先前規劃 Chrome apps 架構被棄用而且 GC extensions 仍然不支援建立 raw socket 的話，
改用 NW.js 平台獨立執行 Chrome apps，
NW.js 或 Electron 平台接近一個獨立的瀏覽器，
如果要常駐成系統服務的話相當耗系統資源。
事實上這個 app 的主要功能是網頁及 WebSocket 伺服器，
使用者介面應該可以改成遠端連線控制，
也就是可以只使用 Node.js 節省系統資源。
至於目前由 app 提供的編碼轉換功能計畫移到網頁執行，
這部分雖然可以直接跑出其他編碼的檔案，
只是檔案太大可能會拖慢速度；
最好的方法應該是在網頁用瀏覽器內建編碼和解碼 API ，
在不支援的瀏覽器用其 polyfill 代替，
不過編碼瀏覽器內建 API 只支援 UTF-8，
剛才的 polyfill 雖然支援其他 charset 的編碼，
只是編碼效能非常差；
另一個選擇是使用 node.js 模組 iconv-lite，
只不過整合到網頁環境的話還要再研究。

另外 Google 網頁建議原先使用 raw socket 的 Chrome apps 改用本機元件，
應該就是用 Native messaging 技術，
Firefox 50+ 也支援這個技術，
所以用這個技術開發的 GC 套件可以直接在 Firefox 上跑。
因為 Firefox 57 後只能用 WebExtensions 而且必要的 socket API 尚未實作，
我暫時先用這個技術把套件架構弄出來，
等到 socket API 實作出來後換上 socket 部分就完成 WebExtensions 版了。

Google 和 Mozilla 提供的 Native messaging 範例程式中本機元件都是 python script，
效能看起來不大好。
這對 socket 連線來說影響很大，
所以我改用事件驅動的 node.js 寫本機元件，
寫出來的套件效能還不錯，
而且連線很穩定不會像之前連線到 Chrome app 的 GC extension 版本常常連不到。

目前 GC extension 版本和 Chrome app 版本相比，
前者只有瀏覽器分頁開啟時才執行，
不像後者需要常駐系統消耗系統資源，
只是前者每多一個 BBS 分頁就多跑一個本機組件，
後者不管開幾個 BBS 分頁就只有一個伺服器程式，
使用時間不長而且不同時開多個分頁的情況適合用前者，
使用時間長而且同時開多個分頁的情況適合用後者。
安裝設定的部分兩者都需要安裝瀏覽器外部組件，
除了使用者很麻煩以外，
完全使用瀏覽器內部功能的單一組件才是最穩定而且最省資源的架構。
另外目前的可共用核心除了支援這兩個架構外也支援即將在 Firefox 57 棄用的 E10s XUL 架構，
E10s XUL 架構的套件在 Firefox 53+ 以後因為 CSP 限制無法直接在 BBS 分頁開啟偏好設定視窗，
要修的話似乎要另外新寫 main process 的程式碼，
目前不打算花大量時間修這個即將棄用的套件，
這個 branch 將來應該只會合併其他 branch 可共用核心的修改。


u881831於 2017年4月2日星期日 UTC+8下午6時35分34秒寫道：