নেটিভ মেসেজিং

গুরুত্বপূর্ণ: Chrome সমস্ত প্ল্যাটফর্মে Chrome অ্যাপগুলির জন্য সমর্থন সরিয়ে দেবে৷ ক্রোম ব্রাউজার এবং ক্রোম ওয়েব স্টোর এক্সটেনশনগুলিকে সমর্থন করতে থাকবে৷ ঘোষণাটি পড়ুন এবং আপনার অ্যাপ স্থানান্তরিত করার বিষয়ে আরও জানুন।

এক্সটেনশন এবং অ্যাপ্লিকেশানগুলি একটি API ব্যবহার করে নেটিভ অ্যাপ্লিকেশনগুলির সাথে বার্তা আদান-প্রদান করতে পারে যা অন্যান্য বার্তা পাসকারী APIগুলির অনুরূপ৷ এই বৈশিষ্ট্যটিকে সমর্থন করে এমন স্থানীয় অ্যাপ্লিকেশনগুলিকে অবশ্যই একটি নেটিভ মেসেজিং হোস্ট নিবন্ধন করতে হবে যা এক্সটেনশনের সাথে কীভাবে যোগাযোগ করতে হয় তা জানে৷ Chrome একটি পৃথক প্রক্রিয়ায় হোস্ট শুরু করে এবং স্ট্যান্ডার্ড ইনপুট এবং স্ট্যান্ডার্ড আউটপুট স্ট্রীম ব্যবহার করে এর সাথে যোগাযোগ করে।

নেটিভ মেসেজিং হোস্ট

একটি নেটিভ মেসেজিং হোস্ট নিবন্ধন করার জন্য অ্যাপ্লিকেশনটিকে অবশ্যই একটি ম্যানিফেস্ট ফাইল ইনস্টল করতে হবে যা নেটিভ মেসেজিং হোস্ট কনফিগারেশনকে সংজ্ঞায়িত করে। নীচে ম্যানিফেস্ট ফাইলের একটি উদাহরণ:

{
  "name": "com.my_company.my_application",
  "description": "My Application",
  "path": "C:\\Program Files\\My Application\\chrome_native_messaging_host.exe",
  "type": "stdio",
  "allowed_origins": [
    "chrome-extension://knldjmfmopnpolahpmmgbagdohdnhkik/"
  ]
}

নেটিভ মেসেজিং হোস্ট ম্যানিফেস্ট ফাইলটি অবশ্যই বৈধ JSON হতে হবে এবং এতে নিম্নলিখিত ক্ষেত্রগুলি থাকতে হবে:

নাম	বর্ণনা
name	নেটিভ মেসেজিং হোস্টের নাম। ক্লায়েন্টরা এই স্ট্রিংটি runtime.connectNative বা runtime.sendNativeMessage- এ পাস করে। এই নামে শুধুমাত্র ছোট হাতের বর্ণমালা, আন্ডারস্কোর এবং ডট থাকতে পারে। নামটি একটি বিন্দু দিয়ে শুরু বা শেষ হতে পারে না এবং একটি বিন্দুর পরে আরেকটি বিন্দু অনুসরণ করা যায় না।
description	সংক্ষিপ্ত অ্যাপ্লিকেশন বিবরণ।
path	নেটিভ মেসেজিং হোস্ট বাইনারিতে পাথ। লিনাক্স এবং ওএসএক্সে পথটি অবশ্যই পরম হতে হবে। উইন্ডোজে এটি ম্যানিফেস্ট ফাইলটি অবস্থিত ডিরেক্টরির সাথে সম্পর্কিত হতে পারে। হোস্ট প্রক্রিয়াটি হোস্ট বাইনারি ধারণকারী ডিরেক্টরিতে সেট করা বর্তমান ডিরেক্টরি দিয়ে শুরু হয়। উদাহরণস্বরূপ যদি এই প্যারামিটারটি C:\Application\nm_host.exe তে সেট করা থাকে তবে এটি বর্তমান ডিরেক্টরি C:\Application\ দিয়ে শুরু হবে।
type	নেটিভ মেসেজিং হোস্টের সাথে যোগাযোগ করতে ব্যবহৃত ইন্টারফেসের প্রকার। বর্তমানে এই প্যারামিটারের জন্য শুধুমাত্র একটি সম্ভাব্য মান আছে: stdio । এটি নির্দেশ করে যে হোস্টের সাথে যোগাযোগ করার জন্য Chrome-এর stdin এবং stdout ব্যবহার করা উচিত।
allowed_origins	নেটিভ মেসেজিং হোস্টে অ্যাক্সেস থাকা উচিত এমন এক্সটেনশনগুলির তালিকা৷ ওয়াইল্ডকার্ড যেমন chrome-extension://*/* অনুমোদিত নয় ৷

নেটিভ মেসেজিং হোস্ট অবস্থান

ম্যানিফেস্ট ফাইলের অবস্থান প্ল্যাটফর্মের উপর নির্ভর করে।

উইন্ডোজে , ম্যানিফেস্ট ফাইলটি ফাইল সিস্টেমের যে কোনও জায়গায় অবস্থিত হতে পারে। অ্যাপ্লিকেশন ইনস্টলার অবশ্যই HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome\NativeMessagingHosts\_com.my_company.my_application_ কী তৈরি HKEY_CURRENT_USER\SOFTWARE\Google\Chrome\NativeMessagingHosts\_com.my_company.my_application_ হবে সম্পূর্ণ পথ ম্যানিফেস্ট ফাইলে। উদাহরণস্বরূপ, নিম্নলিখিত কমান্ড ব্যবহার করে:

REG ADD "HKCU\Software\Google\Chrome\NativeMessagingHosts\com.my_company.my_application" /ve /t REG_SZ /d "C:\path\to\nmh-manifest.json" /f

অথবা নিম্নলিখিত .reg ফাইল ব্যবহার করে:

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\com.my_company.my_application]
@="C:\\path\\to\\nmh-manifest.json"

যখন Chrome নেটিভ মেসেজিং হোস্টের সন্ধান করে, প্রথমে 32-বিট রেজিস্ট্রি জিজ্ঞাসা করা হয়, তারপর 64-বিট রেজিস্ট্রি।

OS X এবং Linux- এ, নেটিভ মেসেজিং হোস্টের ম্যানিফেস্ট ফাইলের অবস্থান ব্রাউজার (Google Chrome বা Chromium) অনুসারে পরিবর্তিত হয়। সিস্টেম-ওয়াইড নেটিভ মেসেজিং হোস্টগুলি একটি নির্দিষ্ট অবস্থানে দেখা হয়, যখন ব্যবহারকারী-স্তরের নেটিভ মেসেজিং হোস্টগুলি NativeMessagingHosts নামক ব্যবহারকারী প্রোফাইল ডিরেক্টরির মধ্যে একটি সাবডিরেক্টরিতে দেখা হয়।

• OS X (সিস্টেম-ওয়াইড)
  • Google Chrome: /Library/Google/Chrome/NativeMessagingHosts/_com.my_company.my_application_.json
  • Chromium: /Library/Application Support/Chromium/NativeMessagingHosts/_com.my_company.my_application_.json
• OS X (ব্যবহারকারী-নির্দিষ্ট, ডিফল্ট পথ)
  • Google Chrome: ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/_com.my_company.my_application_.json
  • Chromium: ~/Library/Application Support/Chromium/NativeMessagingHosts/_com.my_company.my_application_.json
• লিনাক্স (সিস্টেম-ব্যাপী)
  • Google Chrome: /etc/opt/chrome/native-messaging-hosts/_com.my_company.my_application_.json
  • ক্রোমিয়াম: /etc/chromium/native-messaging-hosts/_com.my_company.my_application_.json
• লিনাক্স (ব্যবহারকারী-নির্দিষ্ট, ডিফল্ট পথ)
  • Google Chrome: ~/.config/google-chrome/NativeMessagingHosts/_com.my_company.my_application_.json
  • ক্রোমিয়াম: ~/.config/chromium/NativeMessagingHosts/_com.my_company.my_application_.json

নেটিভ মেসেজিং প্রোটোকল

ক্রোম একটি পৃথক প্রক্রিয়ায় প্রতিটি নেটিভ মেসেজিং হোস্ট শুরু করে এবং স্ট্যান্ডার্ড ইনপুট ( stdin ) এবং স্ট্যান্ডার্ড আউটপুট ( stdout ) ব্যবহার করে এটির সাথে যোগাযোগ করে। উভয় দিকে বার্তা পাঠাতে একই বিন্যাস ব্যবহার করা হয়: প্রতিটি বার্তা JSON ব্যবহার করে ক্রমিক করা হয়, UTF-8 এনকোড করা হয় এবং নেটিভ বাইট ক্রমানুসারে 32-বিট বার্তা দৈর্ঘ্যের সাথে আগে থাকে। নেটিভ মেসেজিং হোস্ট থেকে একটি একক বার্তার সর্বাধিক আকার হল 1 MB, প্রধানত নেটিভ অ্যাপ্লিকেশানগুলি খারাপ আচরণ করা থেকে Chrome কে রক্ষা করতে৷ নেটিভ মেসেজিং হোস্টে প্রেরিত বার্তার সর্বোচ্চ আকার হল 4 জিবি।

নেটিভ মেসেজিং হোস্টের কাছে প্রথম যুক্তি হল কলারের উৎপত্তি, সাধারণত chrome-extension://[ID of allowed extension] । নেটিভ মেসেজিং হোস্ট ম্যানিফেস্টে allowed_origins কী-তে একাধিক এক্সটেনশন নির্দিষ্ট করা হলে এটি নেটিভ মেসেজিং হোস্টদের বার্তার উৎস শনাক্ত করতে দেয়। সতর্কীকরণ : Windows-এ, Chrome 54 এবং তার আগের, প্রথম প্যারামিটারের পরিবর্তে অরিজিনটি দ্বিতীয় প্যারামিটার হিসেবে পাস করা হয়েছিল।

runtime.connectNative ব্যবহার করে একটি মেসেজিং পোর্ট তৈরি করা হলে Chrome নেটিভ মেসেজিং হোস্ট প্রক্রিয়া শুরু করে এবং পোর্টটি ধ্বংস না হওয়া পর্যন্ত এটি চালু রাখে। অন্যদিকে, যখন কোনো মেসেজিং পোর্ট তৈরি না করে runtime.sendNativeMessage ব্যবহার করে কোনো বার্তা পাঠানো হয়, Chrome প্রতিটি বার্তার জন্য একটি নতুন নেটিভ মেসেজিং হোস্ট প্রক্রিয়া শুরু করে। সেক্ষেত্রে হোস্ট প্রক্রিয়া দ্বারা উত্পন্ন প্রথম বার্তাটি মূল অনুরোধের প্রতিক্রিয়া হিসাবে পরিচালনা করা হয়, অর্থাৎ রানটাইম.sendNativeMessage কল করার সময় Chrome এটিকে নির্দিষ্ট প্রতিক্রিয়া কলব্যাকে প্রেরণ করবে। সেই ক্ষেত্রে নেটিভ মেসেজিং হোস্ট দ্বারা উত্পন্ন অন্যান্য সমস্ত বার্তা উপেক্ষা করা হয়।

উইন্ডোজে, নেটিভ মেসেজিং হোস্টকে একটি হ্যান্ডেল সহ একটি কমান্ড লাইন আর্গুমেন্ট পাস করা হয় কলিং ক্রোম নেটিভ উইন্ডোতে: --parent-window=<decimal handle value> . এটি নেটিভ মেসেজিং হোস্টকে নেটিভ UI উইন্ডো তৈরি করতে দেয় যা সঠিকভাবে অভিভাবক। নোট করুন যে কলিং প্রসঙ্গটি একটি পটভূমি স্ক্রিপ্ট পৃষ্ঠা হলে এই মানটি 0 হবে৷

একটি নেটিভ অ্যাপ্লিকেশনের সাথে সংযোগ করা হচ্ছে৷

একটি নেটিভ অ্যাপ্লিকেশন থেকে বার্তা পাঠানো এবং গ্রহণ করা ক্রস-এক্সটেনশন মেসেজিংয়ের অনুরূপ। প্রধান পার্থক্য হল runtime.connect- এর পরিবর্তে runtime.connectNative ব্যবহার করা হয় এবং runtime.sendMessage- এর পরিবর্তে runtime.sendNativeMessage ব্যবহার করা হয়। এই পদ্ধতিগুলি শুধুমাত্র তখনই ব্যবহার করা যেতে পারে যদি আপনার অ্যাপের ম্যানিফেস্ট ফাইলে "নেটিভ মেসেজিং" অনুমতি ঘোষণা করা হয়।

নিম্নলিখিত উদাহরণটি একটি রানটাইম তৈরি করে। পোর্ট অবজেক্ট যা নেটিভ মেসেজিং হোস্ট com.my_company.my_application এর সাথে সংযুক্ত, সেই পোর্ট থেকে বার্তা শোনা শুরু করে এবং একটি বহির্গামী বার্তা পাঠায়:

var port = chrome.runtime.connectNative('com.my_company.my_application');
port.onMessage.addListener(function(msg) {
  console.log("Received" + msg);
});
port.onDisconnect.addListener(function() {
  console.log("Disconnected");
});
port.postMessage({ text: "Hello, my_application" });

runtime.sendNativeMessage একটি পোর্ট তৈরি না করেই নেটিভ অ্যাপ্লিকেশনে একটি বার্তা পাঠাতে ব্যবহার করা যেতে পারে, যেমন:

chrome.runtime.sendNativeMessage('com.my_company.my_application',
  { text: "Hello" },
  function(response) {
    console.log("Received " + response);
  });

নেটিভ মেসেজিং ডিবাগ করা হচ্ছে

যখন নেটিভ মেসেজিং হোস্ট শুরু করতে ব্যর্থ হয়, stderr এ লেখে বা যখন এটি কমিউনিকেশন প্রোটোকল লঙ্ঘন করে, আউটপুট Chrome এর ত্রুটি লগে লেখা হয়। Linux এবং OS X-এ, কমান্ড লাইন থেকে Chrome শুরু করে এবং টার্মিনালে এর আউটপুট দেখে এই লগটি সহজেই অ্যাক্সেস করা যেতে পারে। উইন্ডোজে, --enable-logging ব্যবহার করুন, যেমনটি ব্যাখ্যা করা হয়েছে কিভাবে লগিং সক্ষম করতে হয় ।

সমস্যাগুলি সমাধানের জন্য এখানে কিছু ত্রুটি এবং টিপস রয়েছে:

• নেটিভ মেসেজিং হোস্ট শুরু করতে ব্যর্থ হয়েছে৷
  • ফাইলটি চালানোর জন্য আপনার কাছে পর্যাপ্ত অনুমতি আছে কিনা তা পরীক্ষা করুন।
• অবৈধ নেটিভ মেসেজিং হোস্ট নাম নির্দিষ্ট করা হয়েছে৷
  • নামটিতে কোনো অবৈধ অক্ষর আছে কিনা তা পরীক্ষা করুন। শুধুমাত্র ছোট হাতের আলফানিউমেরিক অক্ষর, আন্ডারস্কোর এবং বিন্দু অনুমোদিত। একটি নাম একটি বিন্দু দিয়ে শুরু বা শেষ হতে পারে না এবং একটি বিন্দুর পরে আরেকটি বিন্দু অনুসরণ করা যায় না।
• নেটিভ হোস্ট প্রস্থান করেছে।
  • Chrome দ্বারা বার্তাটি পড়ার আগে নেটিভ মেসেজিং হোস্টের পাইপটি ভেঙে গেছে। এটি সম্ভবত আপনার নেটিভ মেসেজিং হোস্ট থেকে শুরু করা হয়েছে।
• নির্দিষ্ট নেটিভ মেসেজিং হোস্ট পাওয়া যায়নি.
  • নামটি কি এক্সটেনশন এবং ম্যানিফেস্ট ফাইলে সঠিকভাবে লেখা আছে?
  • ম্যানিফেস্টটি কি সঠিক ডিরেক্টরিতে এবং সঠিক নামের সাথে রাখা হয়েছে? প্রত্যাশিত ফরম্যাটের জন্য নেটিভ মেসেজিং হোস্ট লোকেশন দেখুন।
  • ম্যানিফেস্ট ফাইলটি কি সঠিক বিন্যাসে? বিশেষ করে, JSON সিনট্যাক্স কি সঠিক এবং মানগুলি কি একটি নেটিভ মেসেজিং হোস্ট ম্যানিফেস্টের সংজ্ঞার সাথে মেলে?
  • path মধ্যে নির্দিষ্ট করা ফাইলটি কি বিদ্যমান? উইন্ডোজে, পাথগুলি আপেক্ষিক হতে পারে, কিন্তু ওএস এক্স এবং লিনাক্সে, পাথগুলি অবশ্যই পরম হতে হবে৷
• নেটিভ মেসেজিং হোস্ট হোস্ট নাম নিবন্ধিত নয়. (কেবল-উইন্ডোজ)
  • উইন্ডোজ রেজিস্ট্রিতে নেটিভ মেসেজিং হোস্ট পাওয়া যায়নি। regedit ব্যবহার করে দুবার চেক করুন কী সত্যিই তৈরি করা হয়েছে এবং নেটিভ মেসেজিং হোস্ট অবস্থানে নথিভুক্ত প্রয়োজনীয় বিন্যাসের সাথে মেলে কিনা।
• নির্দিষ্ট নেটিভ মেসেজিং হোস্টে অ্যাক্সেস নিষিদ্ধ।
  • এক্সটেনশনের উৎস কি allowed_origins তালিকাভুক্ত?
• নেটিভ মেসেজিং হোস্টের সাথে যোগাযোগ করার সময় ত্রুটি।
  • এটি একটি খুব সাধারণ ত্রুটি এবং নেটিভ মেসেজিং হোস্টে যোগাযোগ প্রোটোকলের একটি ভুল বাস্তবায়ন নির্দেশ করে৷
  • নিশ্চিত করুন যে stdout এর সমস্ত আউটপুট নেটিভ মেসেজিং প্রোটোকল মেনে চলে। আপনি যদি ডিবাগিংয়ের উদ্দেশ্যে কিছু ডেটা মুদ্রণ করতে চান, stderr এ লিখুন।
  • নিশ্চিত করুন যে 32-বিট বার্তা দৈর্ঘ্য প্ল্যাটফর্মের নেটিভ পূর্ণসংখ্যা বিন্যাসে (লিটল-এন্ডিয়ান / বড়-এন্ডিয়ান)।
  • বার্তার দৈর্ঘ্য 1024*1024 এর বেশি হওয়া উচিত নয়।
  • বার্তার আকার বার্তার বাইটের সংখ্যার সমান হতে হবে। এটি একটি স্ট্রিং এর "দৈর্ঘ্য" থেকে ভিন্ন হতে পারে, কারণ অক্ষরগুলি একাধিক বাইট দ্বারা উপস্থাপিত হতে পারে।
  • শুধুমাত্র উইন্ডোজ: নিশ্চিত করুন যে প্রোগ্রামের I/O মোড O_BINARY তে সেট করা আছে । ডিফল্টরূপে, I/O মোড হল O_TEXT , যা লাইন ব্রেক ( \n = 0A ) উইন্ডোজ-স্টাইল লাইন শেষ ( \r\n = 0D 0A ) দিয়ে প্রতিস্থাপিত হলে বার্তা বিন্যাসকে দূষিত করে। I/O মোড __setmode ব্যবহার করে সেট করা যেতে পারে।