ਅਸੀਂ OWL ਕਿਵੇਂ ਬਣਾਇਆ, ਸਾਡੇ ChatGPT‑ਆਧਾਰਿਤ ਬ੍ਰਾਊਜ਼ਰ Atlas ਦੇ ਪਿੱਛੇ ਦੀ ਨਵੀਂ ਆਰਕੀਟੈਕਚਰ

Ken Rockot, Member of the Technical Staff ਅਤੇ Ben Goodger, Head of Engineering, ChatGPT Atlas ਵੱਲੋਂ

ਪਿਛਲੇ ਹਫ਼ਤੇ, ਅਸੀਂ ChatGPT Atlas ਲਾਂਚ ਕੀਤਾ⁠, ChatGPT ਨੂੰ ਆਪਣੇ ਨਾਲ ਰੱਖ ਕੇ ਵੈੱਬ ਬ੍ਰਾਊਜ਼ ਕਰਨ ਦਾ ਇੱਕ ਨਵਾਂ ਤਰੀਕਾ। ਇੱਕ ਪੂਰੀ-ਸੁਵਿਧਾਵਾਂ ਵਾਲਾ ਵੈੱਬ ਬ੍ਰਾਊਜ਼ਰ ਹੋਣ ਦੇ ਨਾਲ, Atlas ਭਵਿੱਖ ਦੀ ਇੱਕ ਝਲਕ ਵੀ ਦਿੰਦਾ ਹੈ: ਇੱਕ ਅਜਿਹੀ ਦੁਨੀਆ ਜਿੱਥੇ ਤੁਸੀਂ ਸਵਾਲ ਪੁੱਛਣ, ਸੁਝਾਅ ਲੈਣ ਅਤੇ ਆਪਣੇ ਲਈ ਕੰਮ ਪੂਰੇ ਕਰਵਾਉਣ ਲਈ ChatGPT ਨੂੰ ਇੰਟਰਨੈੱਟ ਭਰ ਆਪਣੇ ਨਾਲ ਲੈ ਜਾ ਸਕਦੇ ਹੋ। ਇਸ ਪੋਸਟ ਵਿੱਚ, ਅਸੀਂ ਉਤਪਾਦ ਦੇ ਸਭ ਤੋਂ ਜਟਿਲ ਇੰਜੀਨੀਅਰਿੰਗ ਪੱਖਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਖੋਲ੍ਹਦੇ ਹਾਂ: ਅਸੀਂ ChatGPT ਨੂੰ ਅਜਿਹੇ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲਿਆ ਜੋ ਵਰਤਦੇ ਜਾਣ ਨਾਲ ਹੋਰ ਲਾਭਦਾਇਕ ਬਣਦਾ ਜਾਂਦਾ ਹੈ।

ਵੈੱਬ ਲਈ ChatGPT ਨੂੰ ਇੱਕ ਅਸਲੀ ਕੋ-ਪਾਇਲਟ ਬਣਾਉਣ ਦਾ ਮਤਲਬ ਸੀ ਬ੍ਰਾਊਜ਼ਰ ਦੀ ਪੂਰੀ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਮੁੜ ਸੋਚਣਾ: Atlas ਨੂੰ Chromium runtime ਤੋਂ ਵੱਖ ਕਰਨਾ। ਇਸ ਲਈ Chromium ਨੂੰ ਇਕੱਠੇ ਜੋੜਨ ਦਾ ਇੱਕ ਨਵਾਂ ਤਰੀਕਾ ਬਣਾਉਣਾ ਪਿਆ, ਜਿਸ ਨਾਲ ਅਸੀਂ ਆਪਣੇ ਉਤਪਾਦ ਲੱਛੇ ਪੂਰੇ ਕਰ ਸਕੀਏ: ਤੁਰੰਤ ਸ਼ੁਰੂਆਤ, ਹੋਰ ਟੈਬ ਖੋਲ੍ਹਣ ਦੇ ਬਾਵਜੂਦ ਜਵਾਬਦੇਹੀ, ਅਤੇ ਏਜੰਟ-ਅਧਾਰਿਤ ਵਰਤੋਂ ਮਾਮਲਿਆਂ ਲਈ ਮਜ਼ਬੂਤ ਨੀਂਹ।

Chromium ਇੱਕ ਕੁਦਰਤੀ ਬਿਲਡਿੰਗ ਬਲਾਕ ਸੀ। ਇਹ ਮਜ਼ਬੂਤ ਸੁਰੱਖਿਆ ਮਾਡਲ, ਸਾਬਤ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਬੇਮਿਸਾਲ ਵੈੱਬ ਅਨੁਕੂਲਤਾ ਵਾਲਾ ਆਧੁਨਿਕ ਵੈੱਬ ਇੰਜਨ ਦਿੰਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਸ ਨੂੰ ਇੱਕ ਗਲੋਬਲ ਭਾਈਚਾਰਾ ਵਿਕਸਤ ਕਰਦਾ ਹੈ ਜੋ ਇਸ ਨੂੰ ਲਗਾਤਾਰ ਬਿਹਤਰ ਬਣਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ। ਆਧੁਨਿਕ ਡੈਸਕਟਾਪ ਵੈੱਬ ਬ੍ਰਾਊਜ਼ਰਾਂ ਲਈ ਇਹ ਇੱਕ ਆਮ ਪਹਿਲੀ ਚੋਣ ਹੈ।

ਸਾਡੀ ਪ੍ਰਤਿਭਾਸ਼ਾਲੀ ਡਿਜ਼ਾਈਨ ਟੀਮ ਨੇ ਸਾਡੇ ਯੂਜ਼ਰ ਅਨੁਭਵ ਲਈ ਮਹੱਤਵਾਕਾਂਕਸ਼ੀ ਲੱਛੇ ਰੱਖੇ ਸਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ Agent mode ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ ਭਰਪੂਰ ਐਨੀਮੇਸ਼ਨ ਅਤੇ ਵਿਜ਼ੂਅਲ ਪ੍ਰਭਾਵ ਸ਼ਾਮਲ ਸਨ। ਇਸ ਲਈ ਸਾਡੀ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮ ਨੂੰ ਸਾਡੇ UI ਲਈ ਸਭ ਤੋਂ ਆਧੁਨਿਕ ਨੇਟਿਵ ਫ੍ਰੇਮਵਰਕਾਂ (SwiftUI, AppKit ਅਤੇ Metal) ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪਈ, ਸਿਰਫ਼ open source Chromium UX ਨੂੰ ਨਵੀਂ ਸਤਹ ਦੇਣ ਦੀ ਬਜਾਏ। ਨਤੀਜੇ ਵਜੋਂ, Atlas ਦਾ UI ਪੂਰੇ ਐਪਲੀਕੇਸ਼ਨ UX ਦਾ ਵਿਸਤ੍ਰਿਤ ਮੁੜ-ਨਿਰਮਾਣ ਹੈ।

ਸਾਡੇ ਹੋਰ ਉਤਪਾਦ ਲੱਛੇ ਵੀ ਸਨ, ਜਿਵੇਂ ਤੇਜ਼ startup ਸਮਾਂ ਅਤੇ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਘਟਾਏ ਬਿਨਾਂ ਸੈਂਕੜੇ ਟੈਬਾਂ ਦਾ ਸਮਰਥਨ। Chromium ਨੂੰ ਜਿਵੇਂ ਦਾ ਤਿਵੇਂ ਵਰਤਣ ਨਾਲ ਇਹ ਲੱਛੇ ਹਾਸਲ ਕਰਨਾ ਮੁਸ਼ਕਲ ਸੀ, ਕਿਉਂਕਿ ਇਹ boot sequence, threading model ਅਤੇ tab models ਦੀਆਂ ਕਈ ਵਿਸਥਾਰਾਂ ਬਾਰੇ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਇੱਕ ਧਾਰਨਾ ਰੱਖਦਾ ਹੈ। ਅਸੀਂ ਇੱਥੇ ਵੱਡੇ ਬਦਲਾਅ ਕਰਨ ਬਾਰੇ ਸੋਚਿਆ, ਪਰ ਅਸੀਂ ਚਾਹੁੰਦੇ ਸੀ ਕਿ Chromium ਵਿਰੁੱਧ ਸਾਡੇ patches ਕੇਂਦਰਿਤ ਰਹਿਣ ਤਾਂ ਜੋ ਅਸੀਂ ਨਵੀਆਂ ਵਰਜਨਾਂ ਨੂੰ ਜਲਦੀ ਜੋੜ ਸਕੀਏ। ਆਪਣੀ ਡਿਵੈਲਪਮੈਂਟ ਗਤੀ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਤੇਜ਼ ਰੱਖਣ ਲਈ, ਸਾਨੂੰ Chromium runtime ਨੂੰ ਜੋੜਨ ਅਤੇ ਚਲਾਉਣ ਦਾ ਇਕ ਹੋਰ ਤਰੀਕਾ ਸੋਚਣਾ ਪਿਆ।

ਸਾਡੇ ਤਕਨੀਕੀ ਨਿਵੇਸ਼ ਲਈ ਇੱਕ ਕਸੌਟੀ ਇਹ ਸੀ ਕਿ ਇਹ ਸਿਰਫ਼ ਤੇਜ਼ ਪ੍ਰਯੋਗ, iteration ਅਤੇ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਡਿਲਿਵਰੀ ਯੋਗ ਨਾ ਬਣਾਏ – ਇਹ ਸਾਨੂੰ OpenAI ਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਸੰਸਕ੍ਰਿਤੀ ਦਾ ਇੱਕ ਮੁੱਖ ਹਿੱਸਾ ਵੀ ਕਾਇਮ ਰੱਖਣ ਦੇਵੇ: ਪਹਿਲੇ ਹੀ ਦਿਨ ship ਕਰਨਾ। ਹਰ ਨਵਾਂ ਇੰਜੀਨੀਅਰ ਆਪਣੇ ਪਹਿਲੇ ਦਿਨ ਦੀ ਦੁਪਹਿਰ ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਕਰਦਾ ਅਤੇ merge ਕਰਦਾ ਹੈ। ਸਾਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ ਸੀ ਕਿ ਇਹ ਸੰਭਵ ਰਹੇ, ਭਾਵੇਂ Chromium ਨੂੰ checkout ਕਰਨ ਅਤੇ build ਕਰਨ ਵਿੱਚ ਘੰਟੇ ਲੱਗ ਸਕਦੇ ਹਨ।

ਇਨ੍ਹਾਂ ਚੁਣੌਤੀਆਂ ਲਈ ਸਾਡਾ ਜਵਾਬ ਇੱਕ ਨਵੀਂ ਆਰਕੀਟੈਕਚਰਲ ਪਰਤ ਬਣਾਉਣਾ ਸੀ ਜਿਸ ਨੂੰ ਅਸੀਂ OWL: OpenAI’s Web Layer ਕਹਿੰਦੇ ਹਾਂ। OWL Chromium ਦਾ ਸਾਡਾ integration ਹੈ, ਜਿਸ ਵਿੱਚ Chromium ਦੀ browser process ਨੂੰ ਮੁੱਖ Atlas app process ਤੋਂ ਬਾਹਰ ਚਲਾਉਣਾ ਸ਼ਾਮਲ ਹੈ।

ਇਸ ਨੂੰ ਇਉਂ ਸਮਝੋ: Chromium ਨੇ ਟੈਬਾਂ ਨੂੰ ਵੱਖਰੀਆਂ processes ਵਿੱਚ ਲੈ ਜਾ ਕੇ ਬ੍ਰਾਊਜ਼ਰਾਂ ਵਿੱਚ ਕ੍ਰਾਂਤੀ ਲਿਆਈ। ਅਸੀਂ ਉਸ ਵਿਚਾਰ ਨੂੰ ਹੋਰ ਅੱਗੇ ਲੈ ਜਾ ਰਹੇ ਹਾਂ, Chromium ਨੂੰ ਹੀ ਮੁੱਖ ਐਪਲੀਕੇਸ਼ਨ process ਤੋਂ ਕੱਢ ਕੇ ਇੱਕ ਅਲੱਗ service layer ਵਿੱਚ ਰੱਖ ਕੇ। ਇਹ ਬਦਲਾਅ ਕਈ ਲਾਭਾਂ ਦਾ ਦਰਵਾਜ਼ਾ ਖੋਲ੍ਹਦਾ ਹੈ:

• ਇੱਕ ਸਧਾਰਣ, ਆਧੁਨਿਕ ਐਪ: Atlas ਲਗਭਗ ਪੂਰੀ ਤਰ੍ਹਾਂ SwiftUI ਅਤੇ AppKit ਵਿੱਚ ਬਣਿਆ ਹੈ। ਇੱਕ ਭਾਸ਼ਾ, ਇੱਕ ਟੈਕ ਸਟੈਕ, ਇੱਕ ਸੁਥਰਾ codebase.
• ਤੇਜ਼ startup: Chromium ਪਿਛੋਕੜ ਵਿੱਚ asynchronous ਢੰਗ ਨਾਲ ਬੂਟ ਹੁੰਦਾ ਹੈ। Atlas ਉਡੀਕ ਨਹੀਂ ਕਰਦਾ — ਪਿਕਸਲ ਲਗਭਗ ਤੁਰੰਤ ਸਕ੍ਰੀਨ 'ਤੇ ਆ ਜਾਂਦੇ ਹਨ।
• ਰੁਕਾਵਟਾਂ ਅਤੇ crash ਤੋਂ ਅਲੱਗਾਵ: Chromium ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਅਤੇ ਜਟਿਲ ਵੈੱਬ ਇੰਜਨ ਹੈ। ਜੇ ਇਸ ਦਾ main thread ਅਟਕ ਜਾਵੇ, ਤਾਂ Atlas ਨਹੀਂ ਅਟਕਦਾ। ਜੇ ਇਹ crash ਕਰੇ, ਤਾਂ Atlas ਚਲਦਾ ਰਹਿੰਦਾ ਹੈ।
• merge ਦੀਆਂ ਘੱਟ ਪਰੇਸ਼ਾਨੀਆਂ: ਕਿਉਂਕਿ ਅਸੀਂ Chromium ਦੇ open source UI 'ਤੇ ਇੰਨਾ ਜ਼ਿਆਦਾ ਨਹੀਂ ਬਣਾਉਂਦੇ, upstream Chromium ਨਾਲ ਸਾਡਾ diff ਕਾਫ਼ੀ ਛੋਟਾ ਅਤੇ ਸੰਭਾਲਣਾ ਆਸਾਨ ਹੈ।
• ਤੇਜ਼ iteration: ਜ਼ਿਆਦਾਤਰ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਕਦੇ ਵੀ Chromium ਨੂੰ ਲੋਕਲ ਤੌਰ 'ਤੇ build ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ। OWL ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ prebuilt binary ਵਜੋਂ ship ਹੁੰਦਾ ਹੈ, ਇਸ ਕਰਕੇ Atlas builds ਨੂੰ ਘੰਟਿਆਂ ਦੀ ਬਜਾਏ ਮਿੰਟ ਲੱਗਦੇ ਹਨ।

ਕਿਉਂਕਿ ਸਾਡੀ ਟੀਮ ਦੇ ਬਹੁਤ ਸਾਰੇ ਇੰਜੀਨੀਅਰ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ source ਤੋਂ Chromium build ਨਹੀਂ ਕਰਦੇ, ਇਸ ਲਈ ਡਿਵੈਲਪਮੈਂਟ ਕਾਫ਼ੀ ਤੇਜ਼ ਹੋ ਸਕਦੀ ਹੈ—even ਨਵੇਂ ਟੀਮ ਮੈਂਬਰ ਵੀ ਆਪਣੇ ਪਹਿਲੇ ਦੁਪਹਿਰ ਵਿੱਚ ਸਧਾਰਣ ਬਦਲਾਅ merge ਕਰ ਸਕਦੇ ਹਨ।

ਉੱਚ ਪੱਧਰ 'ਤੇ, Atlas browser OWL Client ਹੈ, ਅਤੇ Chromium browser process OWL Host ਹੈ। ਇਹ IPC ਰਾਹੀਂ ਸੰਚਾਰ ਕਰਦੇ ਹਨ, ਖਾਸ ਤੌਰ 'ਤੇ Mojo⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ), ਜੋ Chromium ਦਾ ਆਪਣਾ message-passing system ਹੈ। ਅਸੀਂ Mojo ਲਈ custom Swift (ਅਤੇ TypeScript ਵੀ) bindings ਲਿਖੀਆਂ, ਤਾਂ ਜੋ ਸਾਡੀ Swift app host-side interfaces ਨੂੰ ਸਿੱਧਾ call ਕਰ ਸਕੇ।

OWL client library ਇੱਕ ਸਧਾਰਣ public Swift API ਮੁਹੱਈਆ ਕਰਦੀ ਹੈ, ਜੋ host ਦੀ service layer ਵੱਲੋਂ ਉਜਾਗਰ ਕੀਤੀਆਂ ਕਈ ਮੁੱਖ ਧਾਰਣਾਵਾਂ ਨੂੰ abstract ਕਰਦੀ ਹੈ:

• Session: host ਨੂੰ ਗਲੋਬਲ ਪੱਧਰ 'ਤੇ ਸੰਰਚਿਤ ਅਤੇ ਨਿਯੰਤਰਿਤ ਕਰੋ
• Profile: ਕਿਸੇ ਖਾਸ user profile ਲਈ browser state ਸੰਭਾਲੋ
• WebView: ਵੱਖ-ਵੱਖ web contents ਨੂੰ ਨਿਯੰਤਰਿਤ ਅਤੇ embed ਕਰੋ (ਜਿਵੇਂ render, input, navigate, zoom ਆਦਿ)
• WebContentRenderer: input events ਨੂੰ Chromium ਦੀ rendering pipeline ਵਿੱਚ ਅੱਗੇ ਭੇਜੋ ਅਤੇ renderer ਤੋਂ ਫੀਡਬੈਕ ਪ੍ਰਾਪਤ ਕਰੋ
• LayerHost/Client: UI ਅਤੇ Chromium ਵਿਚਕਾਰ compositing ਜਾਣਕਾਰੀ ਦੀ ਅਦਲਾ-ਬਦਲੀ ਕਰੋ

ਉੱਚ-ਪੱਧਰੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜਿਵੇਂ bookmarks, downloads, extensions ਅਤੇ autofill ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ service ਐਂਡਪੌਇੰਟਸ ਦੀ ਇਕ ਵਿਸ਼ਾਲ ਰੇਂਜ ਵੀ ਹੈ।

WebViews, ਜੋ client app ਵਿੱਚ ਆਪਸੀ ਤੌਰ 'ਤੇ exclusive presentation space ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਇੱਕ shared compositing container ਵਿੱਚ ਅੰਦਰ-ਬਾਹਰ ਬਦਲੇ ਜਾਂਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, browser window ਵਿੱਚ ਅਕਸਰ ਇੱਕ ਹੀ shared container ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਅਤੇ tab strip ਵਿੱਚ ਕਿਸੇ tab ਨੂੰ ਚੁਣਨ 'ਤੇ ਉਸ tab ਦਾ WebView ਉਸ container ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ। Chromium ਪਾਸੇ, ਇਹ container ਇੱਕ gfx::AcceleratedWidget ਦੇ ਅਨੁਕੂਲ ਹੁੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਆਖ਼ਿਰਕਾਰ ਇੱਕ CALayer ਬੈਕ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਉਸ layer ਦਾ context ID client ਨੂੰ ਉਜਾਗਰ ਕਰਦੇ ਹਾਂ, ਜਿੱਥੇ ਇੱਕ NSView private CALayerHost API ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸਨੂੰ embed ਕਰਦਾ ਹੈ।

<select> dropdowns ਜਾਂ color pickers ਵਰਗੇ ਖਾਸ ਮਾਮਲੇ, ਜਿਨ੍ਹਾਂ ਨੂੰ Chromium ਵੱਖਰੇ popup widgets ਵਿੱਚ render ਕਰਦਾ ਹੈ, ਇਹੋ ਜਿਹਾ ਹੀ ਤਰੀਕਾ ਵਰਤਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਕੋਲ content::WebContents ਨਹੀਂ ਹੁੰਦਾ, ਪਰ ਉਨ੍ਹਾਂ ਕੋਲ ਆਪਣਾ gfx::AcceleratedWidget ਵਾਲਾ content::RenderWidgetHostView ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹੋ delegated rendering model ਲਾਗੂ ਹੁੰਦਾ ਹੈ।

OWL ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ view geometry ਨੂੰ Chromium ਪਾਸੇ ਨਾਲ sync ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਜੋ GPU compositor ਨੂੰ ਉਸੇ ਅਨੁਸਾਰ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾ ਸਕੇ ਅਤੇ ਉਹ ਹਮੇਸ਼ਾਂ ਸਹੀ ਆਕਾਰ ਅਤੇ device scale ਵਾਲੀ layer ਸਮੱਗਰੀ ਤਿਆਰ ਕਰ ਸਕੇ।

ਅਸੀਂ ਇਸ ਤਕਨੀਕ ਨੂੰ Chromium ਦੇ ਆਪਣੇ native Views UI ਦੇ ਤੱਤਾਂ ਨੂੰ ਚੁਣਿੰਦਗੀ ਨਾਲ Atlas ਵਿੱਚ project ਕਰਨ ਲਈ ਵੀ ਦੁਬਾਰਾ ਵਰਤਦੇ ਹਾਂ (ਇਹ SwiftUI ਵਿੱਚ ਬਿਨਾਂ ਸ਼ੁਰੂ ਤੋਂ ਬਦਲ ਬਣਾਏ permission prompts ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਜਲਦੀ bootstrap ਕਰਨ ਲਈ ਵੀ ਲਾਹੇਵੰਦ ਹੈ)। ਇਹ ਤਕਨੀਕ macOS 'ਤੇ installable web apps ਲਈ Chromium ਦੀ ਮੌਜੂਦਾ infrastructure ਤੋਂ ਕਾਫ਼ੀ ਪ੍ਰੇਰਿਤ ਹੈ।

Chromium UI platform events (ਜਿਵੇਂ macOS NSEvents) ਨੂੰ renderers ਤੱਕ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ Blink ਦੇ WebInputEvent model ਵਿੱਚ ਤਬਦੀਲ ਕਰਦਾ ਹੈ। ਪਰ ਕਿਉਂਕਿ OWL Chromium ਨੂੰ ਇੱਕ ਲੁਕਵੇਂ process ਵਿੱਚ ਚਲਾਉਂਦਾ ਹੈ, ਅਸੀਂ ਉਹ ਤਬਦੀਲੀ Swift client library ਦੇ ਅੰਦਰ ਆਪ ਕਰਦੇ ਹਾਂ ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਤਬਦੀਲ ਕੀਤੀਆਂ events ਨੂੰ Chromium ਵੱਲ ਭੇਜ ਦਿੰਦੇ ਹਾਂ।

ਉਥੋਂ, ਇਹ ਉਹੀ lifecycle ਫਾਲੋ ਕਰਦੀਆਂ ਹਨ ਜੋ ਅਸਲੀ input events ਆਮ ਤੌਰ 'ਤੇ web content ਲਈ ਕਰਦੀਆਂ। ਇਸ ਵਿੱਚ ਉਹ events ਵਾਪਸ client ਨੂੰ ਆਉਣਾ ਵੀ ਸ਼ਾਮਲ ਹੈ ਜਦੋਂ ਕੋਈ ਪੰਨਾ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਉਸਨੇ event ਨੂੰ handle ਨਹੀਂ ਕੀਤਾ। ਜਦੋਂ ਇਹ ਹੁੰਦਾ ਹੈ, ਅਸੀਂ NSEvent ਨੂੰ ਮੁੜ synthesize ਕਰਦੇ ਹਾਂ ਅਤੇ ਐਪ ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਨੂੰ input ਨੂੰ handle ਕਰਨ ਦਾ ਮੌਕਾ ਦਿੰਦੇ ਹਾਂ।

Atlas ਦੀ ਏਜੰਟ-ਅਧਾਰਿਤ browsing ਵਿਸ਼ੇਸ਼ਤਾ ਸਾਡੇ rendering, input event forwarding ਅਤੇ data storage ਤਰੀਕਿਆਂ ਲਈ ਕੁਝ ਵਿਲੱਖਣ ਚੁਣੌਤੀਆਂ ਪੈਦਾ ਕਰਦੀ ਹੈ।

ਸਾਡਾ computer use ਮਾਡਲ input ਵਜੋਂ ਸਕ੍ਰੀਨ ਦੀ ਇੱਕੋ ਤਸਵੀਰ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ। ਪਰ ਕੁਝ UI ਤੱਤ, ਜਿਵੇਂ <select> dropdowns, tab ਦੀਆਂ ਹੱਦਾਂ ਤੋਂ ਬਾਹਰ ਵੱਖਰੀਆਂ windows ਵਿੱਚ render ਹੁੰਦੇ ਹਨ। Agent mode ਵਿੱਚ, ਅਸੀਂ ਉਹ popups ਮੁੱਖ page ਚਿੱਤਰ ਵਿੱਚ ਸਹੀ coordinates 'ਤੇ ਵਾਪਸ composite ਕਰਦੇ ਹਾਂ, ਤਾਂ ਜੋ ਮਾਡਲ ਇੱਕ frame ਵਿੱਚ ਪੂਰਾ ਸੰਦਰਭ ਵੇਖੇ।

Input ਲਈ, ਅਸੀਂ ਇਹੋ ਸਿਧਾਂਤ ਲਾਗੂ ਕਰਦੇ ਹਾਂ: ਏਜੰਟ ਦੁਆਰਾ ਬਣਾਏ events ਸਿੱਧੇ renderer ਵੱਲ ਭੇਜੇ ਜਾਂਦੇ ਹਨ, ਕਦੇ ਵੀ privileged browser layer ਰਾਹੀਂ ਨਹੀਂ। ਇਸ ਨਾਲ sandbox boundary automated control ਹੇਠ ਵੀ ਸੁਰੱਖਿਅਤ ਰਹਿੰਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ ਇਸ ਕਿਸਮ ਦੇ events ਅਜੇਹੇ keyboard shortcuts synthesize ਕਰਨ ਜੋ browser ਨੂੰ ਦਿਖਾਈ ਜਾ ਰਹੀ web content ਨਾਲ ਬੇਸਬੰਧ ਕੰਮ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰ ਦੇਣ।

ਏਜੰਟ browsing ਇੱਕ ਅਸਥਾਈ "logged-out" ਸੰਦਰਭ ਵਿੱਚ ਵੀ ਚੱਲ ਸਕਦੀ ਹੈ। ਯੂਜ਼ਰ ਦੀ ਮੌਜੂਦਾ Incognito profile ਸਾਂਝੀ ਕਰਨ ਦੀ ਬਜਾਏ, ਜਿਸ ਨਾਲ state leak ਹੋ ਸਕਦੀ ਹੈ, ਅਸੀਂ Chromium ਦੀ StoragePartition infrastructure ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਲੱਗ, in-memory stores ਚਾਲੂ ਕਰਦੇ ਹਾਂ। ਹਰ ਏਜੰਟ session ਨਵੇਂ ਸਿਰੇ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਇਹ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਸਾਰੇ cookies ਅਤੇ site data ਰੱਦ ਕਰ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਤੁਸੀਂ ਕਈ "logged-out" ਏਜੰਟ sessions ਚਲਾ ਸਕਦੇ ਹੋ, ਹਰ ਇੱਕ ਆਪਣੀ browser tab ਵਿੱਚ ਅਤੇ ਹਰ ਇੱਕ ਹੋਰਾਂ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਲੱਗ।

ਇਹ ਸਭ ਕੁਝ ਗਲੋਬਲ Chromium ਭਾਈਚਾਰੇ ਅਤੇ ਆਧੁਨਿਕ ਵੈੱਬ ਲਈ ਨੀਂਹ ਬਣਾਉਣ ਵਿੱਚ ਉਨ੍ਹਾਂ ਦੇ ਸ਼ਾਨਦਾਰ ਕੰਮ ਤੋਂ ਬਿਨਾਂ ਸੰਭਵ ਨਹੀਂ ਸੀ। OWL ਉਸ ਨੀਂਹ 'ਤੇ ਇੱਕ ਨਵੇਂ ਤਰੀਕੇ ਨਾਲ ਬਣਦਾ ਹੈ: engine ਨੂੰ app ਤੋਂ ਅਲੱਗ ਕਰਕੇ, ਵਿਸ਼ਵ-ਪੱਧਰੀ ਵੈੱਬ ਪਲੇਟਫਾਰਮ ਨੂੰ ਆਧੁਨਿਕ ਨੇਟਿਵ ਫ੍ਰੇਮਵਰਕਾਂ ਨਾਲ ਮਿਲਾ ਕੇ, ਅਤੇ ਇੱਕ ਤੇਜ਼, ਹੋਰ ਲਚਕੀਲੀ ਆਰਕੀਟੈਕਚਰ ਦਾ ਦਰਵਾਜ਼ਾ ਖੋਲ੍ਹ ਕੇ।

ਬ੍ਰਾਊਜ਼ਰ Chromium ਨੂੰ ਕਿਵੇਂ ਰੱਖਦਾ ਹੈ, ਇਸ ਨੂੰ ਮੁੜ ਸੋਚ ਕੇ ਅਸੀਂ ਨਵੇਂ ਕਿਸਮ ਦੇ ਅਨੁਭਵਾਂ ਲਈ ਥਾਂ ਬਣਾ ਰਹੇ ਹਾਂ: ਹੋਰ ਸੁਗਮ startups, ਹੋਰ ਧਨੀ UI, OS ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਨਾਲ ਹੋਰ ਨੇੜਲਾ integration, ਅਤੇ ਐਸੀ development loop ਜੋ ਵਿਚਾਰਾਂ ਦੀ ਰਫ਼ਤਾਰ ਨਾਲ ਚੱਲਦੀ ਹੈ। ਜੇ ਇਹ ਤੁਹਾਡੇ ਲਈ ਠੀਕ ਚੁਣੌਤੀ ਲੱਗਦੀ ਹੈ, ਤਾਂ Atlas 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ ਸਾਡੀਆਂ openings ਵੇਖੋ, ਜਿਵੇਂ Software Engineer, Atlas⁠, Software Engineer, iOS⁠, ਅਤੇ ਹੋਰ⁠.

Atlas ਅਜ਼ਮਾਓ chatgpt.com/atlas⁠⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) 'ਤੇ.