Pangkalahatang-ideya ng operasyon

Inilalarawan ng mga sumusunod na seksyon ang mahahalagang konsepto para sa matagumpay na operasyon ng Glasswall Embedded Engine.

Mga Session​

Ang Application Programming Interface (API) ay nakabatay sa session. Ang Session ay isang uri na kumakatawan sa isang file at sa mga mekanismong ginagamit upang iproseso ang file na iyon.

• You create a Session object by calling GW2OpenSession which returns a session handle.
  • Dahil maaaring higit sa isang session ang aktibo, ginagamit ang Session ID upang ma-access ang data at magtakda ng mga variable para sa isang partikular na session.
• Ipinapasa mo ang session handle sa iba pang API function upang mairehistro ang mga input at output at ang mga anyo ng mga input at output (memory o isang file).
• Pagkatapos, ipoproseso mo ang file sa pamamagitan ng pagtawag sa function na GW2RunSession at isasara ang session sa pamamagitan ng pagtawag sa GW2CloseSession.

Kapag binuksan, ang bawat session ay binibigyan ng sarili nitong serye ng mga memory buffer. Nananatiling naa-access ang mga buffer na ito hangga't nananatiling bukas ang session. Kapag naisara na ang isang session, hindi na available ang data at ang inilaan na memory ay nire-release.

Ang isang session ay dapat laging isara. Kabilang dito ang mga sitwasyon kung saan may nangyaring isyu sa pagproseso at napuputol ang inaasahang daloy ng operasyon. Sa ganitong pagkakataon, maaaring gamitin ang maraming defensive coding pattern na idinisenyo para sa pamamahala ng resources hal. try-with-resources sa Java, o context-handlers sa Python.

Tandaan na habang mas maraming session ang sabay-sabay na bukas, mas lalaki ang kabuuang pangangailangan sa memory. Hindi suportado ang pagproseso ng mga file gamit ang maraming thread. Ang pag-spawn ng maraming process ay ipinapayo upang mapadali ang parallel processing.

Ang karagdagang impormasyon tungkol sa mga API ng Embedded Engine ay nakadokumento sa mga kaugnay na pahina ng function ng API.

Mga policy file​

Ginagamit ang isang policy file upang matukoy kung paano dapat iproseso ng Glasswall ang mga ibinigay na file. Isang halimbawang policy file ang ibinibigay sa release package ng Embedded Engine.

Bagama’t hindi kinakailangan ang isang policy file para tumakbo ang Glasswall, sa karamihan ng mga kaso ay gumagamit nito upang i-customize ang pagproseso ayon sa mga kinakailangan. Kung gagamit ng policy file, dapat itong irehistro sa bawat session.

Kung walang tinukoy na policy file, ang mga setting ng content management ay itatakda sa sanitise na mga file bilang default. Ilalapat din ang mga default na setting para sa mga opsyon ng sysConfig.

Tingnan ang Content Management at System Configuration para sa karagdagang impormasyon.

Mga return value mula sa Glasswall​

Karamihan sa mga function sa loob ng Glasswall API ay nagbabalik ng integer na nagsasaad ng tagumpay o pagkabigo. Ang 0 o 1 ay magsasaad ng tagumpay, samantalang ang negatibong numero (gaya ng -1) ay magsasaad ng pagkabigo.

May ilang API call na hindi sumusunod sa pattern na ito; halimbawa, ang function na GW2OpenSession ay magbabalik ng alinman sa -1 na error o ng ID ng bagong likhang session (positibong integer). Ang talahanayan ng mga return value ay makikita sa pahinang API Overview.

Pamamahala ng data​

Pinoproseso at sine-save ng Glasswall ang data gamit ang mga file at/o buffer. Ang mga kinakailangan sa data para sa mga prosesong ito ay inilalarawan sa mga seksyon sa ibaba.

Mga file​

Ang mga file-based na Glasswall API call ay nangangailangan ng file path bilang parameter. Ang file name na ito ay dapat naka-encode bilang C-type string; isang array ng mga character na tinatapos ng NULL character. Dapat gamitin ang UTF-8 encoding.

Memory​

Ang mga memory-based na Glasswall API call ay nangangailangan ng paggamit ng isa o higit pang memory buffer. Ang mga buffer na ito ay tinutukoy ng pointer sa unang element at ng haba ng buffer sa bytes. Ang paraang ito ay nagbibigay-daan upang maproseso nang tama ang mga file na naglalaman ng NULL character.

Mga function ng Import/Input​

Ang mga function na ito ay nangangailangan ng pointer sa unang datum sa buffer at ng haba ng buffer sa bytes.

Mga function ng Export/Output​

Tinutukoy ng mga function na ito ang buffer na dapat gamitin ng Glasswall kapag ibinabalik ang naprosesong data. Nangangailangan ang Glasswall ng mga pointer kapwa sa haba ng buffer at sa pointer sa unang element, gaya ng inilalarawan sa ibaba:

• Isang pointer-to-pointer sa unang elemento ng buffer
• Isang pointer sa haba ng buffer (size_t *)

Kinakailangan ang karagdagang layer na ito ng abstraction dahil hindi alam ang laki ng buffer na ito bago patakbuhin ang session. Ang pag-dereference sa mga pointer na ito ay nagbibigay-daan sa pag-access sa data na ibinalik mula sa Glasswall.