ব্রাউজারে লোকাল ফাইল প্রসেসিং কীভাবে কাজ করে
কিছুই যদি আপলোড না হয়, তাহলে কাজটা আসলে করছে কে — আর কোথায়?
এখানে “লোকাল” বলতে কী বোঝায়
চিরাচরিত অনলাইন কনভার্টার মানে একটা আপলোড এন্ডপয়েন্ট আছে এমন ওয়েবসাইট। আপনার ফাইল এমন একটা মেশিনে পাঠানো হয় যা আপনার নিয়ন্ত্রণে নেই, সেখানেই প্রসেস হয়, কিছুদিন জমা থাকে, আর ডাউনলোড হিসেবে ফেরত দেওয়া হয়। লোকাল প্রসেসিং এই বাক্যটার মাঝখানটা মুছে দেয়: আপনার ফাইল যে কোড পড়ে সেটা চলে আপনার আগে থেকেই খোলা ব্রাউজার ট্যাবের ভেতরে, আপনার নিজের প্রসেসরে, আর ফলাফল লেখা হয় আপনার নিজের ডিস্কেই।
সাইটটা তখনও নেটওয়ার্ক দিয়েই আসে — HTML, স্টাইলশিট, স্ক্রিপ্ট আর WebAssembly মডিউল সবই যেকোনো ওয়েব পেজের মতোই সার্ভার থেকে আসে। পার্থক্যটা দিকের। প্রোগ্রামের কোড নিচে নামে; আপনার ফাইল উপরে ওঠে না।
যন্ত্রাংশগুলো ব্রাউজারেই আছে
| সুবিধা | এটা কী দেয় |
|---|---|
| File আর Blob API | ফর্ম সাবমিট না করেই ব্যবহারকারীর বেছে নেওয়া বা টেনে ফেলা ফাইলের বাইট পড়া |
| Web Workers | ভারী কাজ ব্যাকগ্রাউন্ড থ্রেডে চালানো, যাতে ইন্টারফেস সাড়া দিতে থাকে |
| WebAssembly | কম্পাইল করা C, C++ বা Rust কোডেক লাইব্রেরি প্রায় নেটিভ গতিতে চালানো |
| Canvas আর OffscreenCanvas | ইমেজ ডিকোড করা, আঁকা, রিসাইজ করা আর আবার এনকোড করা |
| WebCodecs | ব্রাউজারের নিজস্ব হার্ডওয়্যার-অ্যাক্সিলারেটেড ভিডিও এনকোডার ও ডিকোডার পর্যন্ত পৌঁছানো |
| WebGPU | গ্রাফিক্স প্রসেসরে মডেল ইনফারেন্স আর সমান্তরাল পিক্সেলের কাজ চালানো |
| File System Access | সমর্থন থাকলে ফলাফল সরাসরি ব্যবহারকারীর বেছে নেওয়া জায়গায় লেখা |
এর কিছুই বিরল কোনো জিনিস নয়। এটা সেই একই প্ল্যাটফর্ম, যা ট্যাবের ভেতরে স্প্রেডশিট, ডিজাইন টুল আর গেম চালায়। একমাত্র অস্বাভাবিক সিদ্ধান্তটা হলো এর সঙ্গে সার্ভার জুড়তে অস্বীকার করা।
একটা ফাইল যে পথে চলে
- আপনি একটা ফাইল বাছেন। ব্রাউজার পেজটাকে তার একটা হ্যান্ডল দেয় — কপি নয়, একটা রেফারেন্স।
- পেজটা এক্সটেনশনের উপর ভরসা না করে প্রথম কয়েকটা বাইট পড়ে সিগনেচার থেকে ফাইলের আসল ধরন শনাক্ত করে।
- কাজটার কত মেমোরি লাগবে তার একটা হিসাব করে, আর সেটা ডিভাইস নিরাপদে যতটা দিতে পারে তার বেশি হলে কাজটা করতে অস্বীকার করে বা সারিতে রাখে।
- বাইটগুলো একটা Web Worker-এ পাঠানো হয়। ArrayBuffer পাঠানো মানে কপি করা নয়, মালিকানা হস্তান্তর করা, তাই বড় ফাইল মেমোরিতে দুবার থাকে না।
- ওয়ার্কারের ভেতরে একটা WebAssembly কোডেক বা প্ল্যাটফর্মের কোনো API আসল ডিকোডিং আর এনকোডিংয়ের কাজটা করে।
- ফলাফল বাইট হিসেবে ফিরে আসে, একটা Blob-এ মোড়া হয়, আর আপনাকে ডাউনলোড হিসেবে দেওয়া হয় বা আপনার বেছে নেওয়া জায়গায় লেখা হয়।
- ওই Blob-এর অস্থায়ী URL বাতিল করা হয় আর বাফারগুলো ছেড়ে দেওয়া হয়।
WebAssembly-ই কেন বদলে দেওয়া অংশটা
ইমেজ আর ভিডিও কোডেক মানে কয়েক দশক ধরে যত্ন করে অপটিমাইজ করা C। JavaScript-এ সেগুলো নতুন করে লেখা কখনোই বাস্তবসম্মত ছিল না। WebAssembly একটা পোর্টেবল বাইনারি ইনস্ট্রাকশন ফরম্যাট, যা ব্রাউজার একটা স্যান্ডবক্সে নেটিভ কোডের কাছাকাছি গতিতে চালায়, অর্থাৎ আগে থেকে থাকা ওই লাইব্রেরিগুলো যেমন আছে তেমনই কম্পাইল করে ব্রাউজারে পাঠানো যায়।
গতির মতোই জরুরি স্যান্ডবক্সটা। একটা WebAssembly মডিউলের আপনার ফাইল সিস্টেম, নেটওয়ার্ক বা অন্য ট্যাবে কোনো সহজাত প্রবেশাধিকার নেই। পেজ তাকে যে মেমোরিটুকু দেয় সে শুধু সেটাই দেখে, আর কিছুই নয়। ক্ষতিকর বা নিছক ত্রুটিপূর্ণ কোনো কোডেক এদিক-ওদিক ঘুরে এমন কিছু পড়তে পারে না যা তাকে দেওয়া হয়নি।
এখনও নেটওয়ার্ক কী কী ছোঁয়, আর সেটা কেন আপনার ফাইল নয়
নেটওয়ার্ক দিয়ে তিনটি জিনিস আসে: পেজটা নিজে, আপনি যে টুল খুলেছেন তার ইঞ্জিন, আর — ব্যাকগ্রাউন্ড সরানোর জন্য — মডেলের ওয়েট। তিনটিই FileSlimmer-এর নিজস্ব স্ট্যাটিক অ্যাসেট, আর আপনার একটা বাইটও পড়ার আগেই FileSlimmer-এর নিজের অরিজিন থেকে সেগুলো আনা হয়। এগুলো ডাউনলোড, এগুলো ক্যাশ করা যায়, আর প্রথমবার ব্যবহারের পর নেটওয়ার্ক ছাড়াই ব্রাউজারের নিজের ক্যাশ থেকে এগুলো সরবরাহ করা যায়।
এর পরের সবকিছুই লোকাল। ইঞ্জিনগুলো ফাইলের বাইট পায় কেবল পেজ থেকে postMessage-এর মাধ্যমে; কিছু পাঠানোর জন্য তাদের কখনও কোনো URL দেওয়া হয় না, আর কোনো কোড চেষ্টা করলেও পেজটা কোথায় সংযোগ করতে পারবে তা একটা কনটেন্ট সিকিউরিটি পলিসি বেঁধে দেয়।
লাভ-ক্ষতির হিসাব, সরাসরি
| বিবেচনা | আপনার ব্রাউজারে | সার্ভারে |
|---|---|---|
| আপনার ফাইল কোথায় যায় | কোথাও না | আপনার নিয়ন্ত্রণে নেই এমন একটা মেশিনে |
| গতি | আপনার ডিভাইস যতটা পারে | পরিচালক যতটার জন্য টাকা দিয়েছে |
| খুব বড় ফাইল | ব্রাউজারের মেমোরিতে সীমাবদ্ধ | পরিচালকের বেঁধে দেওয়া সীমায় সীমাবদ্ধ |
| অফলাইনে চলে | ইঞ্জিন একবার ক্যাশ হয়ে গেলে, হ্যাঁ | না |
| বিরল ফরম্যাট | শুধু যা WebAssembly-তে কম্পাইল হয় | পরিচালক যা ইনস্টল করেন সবই |
| এক হাজার ফাইলের ব্যাচ | ডিভাইসের সীমায় আটকা | সাধারণত বেশি মানানসই |
লোকাল প্রসেসিং সব ক্ষেত্রেই ভালো নয়। ফাইলটা ব্যক্তিগত হলে, ডিভাইসটা সক্ষম হলে আর কাজটা মেমোরিতে আঁটলে এটাই ভালো। একটা মেশিনে যতটা ধরে তার চেয়ে অনেক বেশি প্রসেস করতে হলে সার্ভারই ভালো। এক পদ্ধতি সব জায়গায় জেতে বলে জেদ ধরার চেয়ে আপনি কোন পরিস্থিতিতে আছেন তা নিয়ে পরিষ্কার থাকাটা বেশি কাজের।
এখানে যা দাবি করা হচ্ছে না
এটা এই অ্যাপ্লিকেশন কী করে তার একটা বিবৃতি। এটা আপনার ব্রাউজার এক্সটেনশন নিয়ে কোনো দাবি নয় — সেগুলো আপনার খোলা যেকোনো পেজের কনটেন্ট পড়তে পারে; আপনার অপারেটিং সিস্টেম নিয়েও নয় — সেটা আপনার ছোঁয়া যেকোনো ফাইল পরীক্ষা করতে পারে; আপনার নেটওয়ার্ক অপারেটর নিয়েও নয় — তারা দেখতে পায় আপনি কোনো সাইটে গিয়েছেন। এগুলো কোনো ওয়েবসাইটেরই নাগালের বাইরে, আর যে টুল আপনাকে অন্য কথা বলে সে নিজের দাবি বাড়িয়ে বলছে।
দাবিটা সীমিত এবং যাচাইযোগ্য: আপনার বেছে নেওয়া ফাইলগুলো এই ব্রাউজারেই লোকালি প্রসেস হয় আর FileSlimmer সেগুলো আপলোড করে না। বিশ্বাস করে বসে না থেকে কীভাবে নিজেই সেটা যাচাই করবেন, পরের গাইডে তা বলা আছে।
এই কাজের টুল
সূত্র
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs