ऑपरेशन का अवलोकन

निम्नलिखित अनुभाग सफल Glasswall Embedded Engine operation के लिए मुख्य अवधारणाओं का वर्णन करते हैं।

सेशन्स​

Application Programming Interface (API) session-आधारित है। Session एक प्रकार है जो किसी फ़ाइल और उस फ़ाइल को प्रोसेस करने के लिए उपयोग किए जाने वाले तंत्रों का प्रतिनिधित्व करता है।

• You create a Session object by calling GW2OpenSession which returns a session handle.
  • चूँकि एक से अधिक session सक्रिय हो सकते हैं, इसलिए किसी विशेष session के लिए डेटा एक्सेस करने और variables सेट करने हेतु Session ID का उपयोग किया जाता है।
• इनपुट और आउटपुट, तथा इनपुट और आउटपुट के रूपों (memory या file) को रजिस्टर करने के लिए आप session handle को अन्य API functions में पास करते हैं।
• इसके बाद आप GW2RunSession function को कॉल करके फ़ाइल को प्रोसेस करते हैं और GW2CloseSession को कॉल करके session बंद करते हैं।

खोले जाने पर, प्रत्येक session को memory buffers की अपनी अलग श्रृंखला आवंटित की जाती है। ये buffers तब तक सुलभ रहते हैं जब तक session खुला रहता है। जैसे ही session बंद होता है, डेटा अब उपलब्ध नहीं रहता और आवंटित memory रिलीज़ कर दी जाती है।

एक session को हमेशा बंद किया जाना चाहिए। इसमें वे स्थितियाँ भी शामिल हैं जहाँ processing से जुड़ी कोई समस्या उत्पन्न होती है और संचालन का अपेक्षित flow बाधित हो जाता है। ऐसी स्थिति में, resources को प्रबंधित करने के लिए डिज़ाइन किए गए कई defensive coding patterns अपनाए जा सकते हैं, जैसे Java में try-with-resources या Python में context-handlers।

ध्यान दें कि जितने अधिक sessions एक साथ खुले होंगे, कुल memory आवश्यकताएँ उतनी ही अधिक होंगी। multiple threads का उपयोग करके files को प्रोसेस करना समर्थित नहीं है। एकाधिक processes शुरू करने की सलाह दी जाती है ताकि parallel processing को सक्षम किया जा सके।

Embedded Engine API's के बारे में अधिक जानकारी संबंधित API function pages में प्रलेखित है।

policy फ़ाइलें​

यह निर्धारित करने के लिए एक policy फ़ाइल का उपयोग किया जाता है कि Glasswall प्रदान की गई files को कैसे प्रोसेस करे। Embedded Engine release package में एक sample policy फ़ाइल प्रदान की जाती है।

हालाँकि Glasswall को चलाने के लिए किसी policy file की आवश्यकता नहीं होती, अधिकांश मामलों में आवश्यकताओं के अनुरूप processing को अनुकूलित करने के लिए इसका उपयोग किया जाता है। यदि किसी policy file का उपयोग किया जाना है, तो उसे प्रत्येक session के लिए registered होना चाहिए।

यदि कोई policy file निर्दिष्ट नहीं की जाती है, तो content management settings डिफ़ॉल्ट रूप से files को sanitise पर सेट करती हैं। sysConfig options के लिए भी default settings लागू होंगी।

अधिक जानकारी के लिए Content Management और System Configuration देखें।

Glasswall से return values​

Glasswall API के भीतर अधिकांश functions success या failure को दर्शाने वाला एक integer लौटाते हैं। 0 या 1 success को दर्शाएगा, जबकि एक negative number (जैसे -1) failure को दर्शाएगा।

कुछ API calls इस pattern का पालन नहीं करतीं; उदाहरण के लिए, GW2OpenSession function या तो -1 error लौटाएगा या नए बनाए गए session की ID (positive integer)। return values की एक table API Overview page पर मिल सकती है।

Data management​

Glasswall files और/या buffers का उपयोग करके data को process और save करता है। इन processes के लिए data requirements नीचे दिए गए sections में वर्णित हैं।

Files​

File-based Glasswall API calls में parameter के रूप में एक file path आवश्यक होता है। इस file name को C-type string के रूप में encode किया जाना चाहिए; अर्थात characters की एक array जो NULL character पर समाप्त होती है। UTF-8 encoding का उपयोग किया जाना चाहिए।

Memory​

Memory-based Glasswall API calls में एक या अधिक memory buffers का उपयोग आवश्यक होता है। इन buffers को पहले element के pointer और bytes में buffer की length द्वारा परिभाषित किया जाता है। यह तरीका NULL characters वाली files को सही ढंग से process करने की अनुमति देता है।

Import/Input functions​

इन functions के लिए buffer में पहले datum के pointer और bytes में buffer की length आवश्यक होती है।

Export/Output functions​

ये functions उस buffer को निर्दिष्ट करती हैं जिसका उपयोग Glasswall processed data लौटाते समय करेगा। नीचे वर्णित अनुसार, Glasswall को buffer length और पहले element के pointer दोनों के pointers की आवश्यकता होती है:

• बफ़र के पहले एलिमेंट के लिए एक pointer-to-pointer
• बफ़र की लंबाई के लिए एक pointer (size_t *)

अमूर्तन की यह अतिरिक्त परत आवश्यक है क्योंकि session चलाने से पहले इस बफ़र का आकार ज्ञात नहीं होता। इन pointers को dereference करने से Glasswall से लौटाए गए डेटा तक पहुंच मिलती है।