"OpenDoc" คําจํากัดความใหมของระบบเปด สุรพล ศรีบุญทรง

บทความป 1995

"Document-based computing" การประมวลผลรูปใหม

ปรากฏการณสําคัญที่นาสนใจอยางหน่ึงซึ่งปรากฏข้ึนในวงการอุตสาหกรรมคอมพิวเตอรในชวงหลาย

ปที่ผานมาน้ี คือ เหลาบริษัทผูผลิตผลิตภัณฑคอมพิวเตอรตางพากันหันเห

ตนเองเขาสูเทคโนโลยีการประมวลผลแบบ Document-based computing

ซึ่งเปนรูปแบบการประมวลผลที่เนนตัวเอกสาร (document) อันเปนผลลัพธ

โดยรวมที่ปรากฏสูสายตาของผูใชคอมพิวเตอรเปนสําคัญ แทนที่จะเนนไปที่

ตัวโปรแกรมประยุกตซึ่งสรางเอกสารดังกลาวข้ึนมา (Application-based

computing) เชนรูปแบบการที่เคยนิยมกันแตไหนแตไรมา

อาจกลาวไดวาการประมวลผลแบบ Document-based

computing น้ีเปนรูปแบบการประมวลผลในอนาคตที่เหลาผูใชคอมพิวเตอร

อยางเราๆ ทานๆ คงจะตองสัมผัสใชงานมันอยางแนนอนไมวาจะเปนใน

ขณะน้ี หรืออีกไมกี่ปขางหนา รูปแบบการประมวลผลแบบ Document-

based computing เริ่มเปนที่รูจักกันครั้งแรกก็ในชวงราวๆ คริสตทศวรรษที่ 70 จากผลิตภัณฑของบริษัท Xerox

หลังจากน้ันมันก็ไดรับการพัฒนาใหมีประสิทธิภาพเพิ่มข้ึนอยางตอเน่ืองตลอดเวลา

สําหรับรูปแบบของการประมวลผลแบบ Document-based computing ที่เหลาผูใชคอมพิวเตอร

อยางเราๆ ทานๆ รูจักกันเปนอยางดี ก็เห็นจะไดแก ระบบ OLE (Object Linking and Embedding) ของบริษัท

ไมโครซอฟทซึ่งใชวิธีกําหนดองคประกอบภายในเอกสารบนหนาจอคอมพิวเตอรเปนออพเจ็คท (object) หลายๆออพ

เจ็คท (แตละออพเจ็คทอาจจะถูกสรางมาจากโปรแกรมประยุกตเดียวกัน หรือตางโปรแกรมกันก็ได)

ความที่แตละเอกสารซึ่งถูกสรางข้ึนดวยระบบการประมวลผลแบบ Document-based

computing อยาง OLE น้ีเปนผลรวมที่เกิดมาจากออพเจ็คทหลายๆ ออพเจ็คท จากโปรแกรมประยุกตหลายๆ

โปรแกรม เราจึงมักจะเรียกเอกสารดังกลาวน้ีวาเปน "เอกสารประกอบ หรือ Compound document" และตัว

Compound document น่ีเองที่จัดไดวาเปนแกนกลาง หรือหัวใจของระบบการประมวลผลแบบ Document-

based computing

2

ภายใตการทํางานของระบบ OLE น้ัน ผูใชคอมพิวเตอรสามารถนําเอาออพเจ็คทรูปตารางหรือ

กราฟแผนผังซึ่งถูกสรางข้ึนจากโปรแกรมประยุกตประเภทสเปรดชีตอยาง โปรแกรม excel, ออพเจ็คทรูปภาพบิท

แม็ทที่ถูกสรางจากโปรแกรมประยุกตประเภท

Art & Letter เขาไปประกอบภายในเอกสาร

ขอความซึ่งสรางข้ึนจากโปรแกรมประเภทเวิรด

ไดอยางสะดวกงายดายและมีประสิทธิภาพ

เวลาจะแกไขดัดแปลงอะไรภายในออพเจ็คทก็

สามารถเรียกโปรแกรมประยุกตซึ่งเปนเจาของ

ออพเจ็คทข้ึนมาทํางานจากตัวเอกสาร

Compound document ไดโดยตรงเลย

ไมวาระบบ OLE จะสามารถ

ประกอบออพเจ็คทตางๆ เขาไวในเอกสาร

Compound document ไดอยางมี

ประสิทธิภาพมากเพียงไรก็ตาม แตมันก็ยังคง

จํากัดการทํางานอยูภายในกลุมของโปรแกรม

ประยุกตที่ถูกออกแบบมาเพื่อการทํางานบน

ระบบปฏิบัติการวินโดวส และทํางานบนเครื่อง

คอมพิวเตอรตระกูลพีซี (PCs) เทาน้ัน ไม

อนุญาตใหนําเอาออพเจ็คทซึ่งสรางจาก

โปรแกรมประยุกตจากระบบคอมพิวเตอรแมค

อินทอช หรือจากแพล็ตฟอรมอื่นๆ เขามา

ประกอบในตัวเอกสาร Compound document ได (อาจจะนําออพเจ็คทจากตางระบบเขามาประกอบได แตก็ไม

สามารถเรียกโปรแกรมซึ่งเปนเจาของออพเจ็คทกลับข้ึนมาดัดแปลงแกไขออพเจ็คทดังกลาวไดอยูดี)

เพื่อแกปญหาเรื่องขอจํากัดในเรื่องการยายงานไปทําในคอมพิวเตอรแพล็ตฟอรมตางระบบ เหลา

บริษัทผูผลิตซอฟทแวรคอมพิวเตอรรุนหลังๆ จึงพยายามออกแบบผลิตภัณฑของตนใหเปดกวาง และเปนสากล

(open system) มากที่สุดเทาที่จะมากได แนนอน แนวโนมเรื่องความเปนระบบเปดที่วาน้ียอมสงผลกระทบตอ

การประมวลผลแบบ Document-based computing อยางมิอาจหลีกเลี่ยงได ในฐานะที่มันเปนการทํางานบน

เอกสาร Compound document ที่เกี่ยวของกับโปรแกรมประยุกตหลายๆ โปรแกรม

ดังน้ันผลิตภัณฑ Document-based computing รุนลาสุดอยาง "OpenDoc" จึงถูกออกแบบมาให

มีลักษณะเปนกลางสามารถใชไดกับโปรแกรมประยุกตจากเหลาบริษัทผูผลิตไดอยางไมจํากัดย่ีหอ (vendor-neutral)

ซึ่งนาจะเปนมาตรฐานระบบเปด (open standard) สําหรับรูปแบบของเอกสาร Compound document ใน

3

อนาคต ที่สามารถประกอบไปดวยขอมูลทุกประเภท ไมวาจะเปน ตาราง, แผนผัง, กราฟ, ตัวอักษร, หรือจนกระทั่ง

สัญญาณวิดีโอ, สัญญาณเสียง, โน็ตการด และภาพกราฟฟกสามมิติ ฯลฯ

เจาะลึกระบบ OpenDoc

ในทางทฤษฎีน้ัน OpenDoc จะอนุญาตใหผูใชคอมพิวเตอรดัดแปลงแกไขออพเจ็คททุกออพเจ็คท

ที่ประกอบอยูภายในเอกสาร Compound document ดวยโปรแกรมประยุกตซึ่งเปนเจาของออพเจ็คท (ตอแตน้ีไป

จะเรียกโปรแกรมประยุกตซึ่งเปนเจาของออพเจ็คท และสามารถดัดแปลงแกไขออพเจ็คทไดวา "Editor") ไดอยาง

อิสระไปพรอมๆ กัน (same time editing) มิใชปลอยใหโปรแกรม editor โปรแกรมใดโปรแกรมหน่ึงครอบครอง

เอกสารไปโดยเด็ดขาด เชนรูปแบบการประมวลผลแบบเดิม

การที่ OpenDoc อนุญาตใหโปรแกรม editor หลายๆ โปรแกรมสามารถจัดการกับออพเจ็คท

ภายในเอกสาร Compound document ไปพรอมๆ กันไดน้ัน ทําใหจําเปนตองมีการขีดแบงพื้นที่ครอบครองของ

แตละออพเจ็คทแยกจากกันอยางชัดเจนแนนอน (คลายๆ กับการรังวัดที่ดินของกรมที่ดินอยางไรอยางน้ันแหละ) มิ

ฉน้ันอาจจะมีการพิพาท หรือลวงล้ําพื้นที่ใชงานซึ่งกันและกันระหวางโปรแกรม editor และหาขอสรุปไมไดวาใคร

ควรจะเปนผูครอบครองพื้นที่ซึ่งอยูระหวางออพเจ็คท (พื้นที่ใชงานของแตละ editor ของ OpenDoc น้ันมีศัพท

เฉพาะวา "parts")

แตการขีดแบงพื้นที่ครอบครองของแตละออพเจ็คทออกจากกันเปนสวนๆ น้ัน ก็อาจจะนําไปสูการ

สูญเสียขีดความสามารถบางอยางของการประมวลผลแบบ Document-based computing เชน ความสามารถใน

การฝงตัวของออพเจ็คท (embedding) เพราะการฝงตัวน้ันหมายถึงวาจะตองมีการลวงล้ําของออพเจ็คทหน่ึงเขาไป

ในสวน part ของอีกออพเจ็คทหน่ึงทั้งตัวเลยเสียดวยซ้ํา และหลังจากการฝงตัวออพเจ็คทหน่ึงเขาไปในอีกออพเจ็คท

หน่ึงแลว แตละออพเจ็คทก็จะตองดํารงสถานภาพเดิมของตนไวอยูตลอดเวลา (คลายกับการฝงลูกเกต หรือหมูหยอง

เขาไวในขนมปงอยางไรอยางน้ัน หลังจากฝงตัวแลว ลูกเกตก็ยังเปนลูกเกต, หมูหยองยังเปนหมูหยอง และขนมปงก็

ยังคงเปนขนมปงอยูเชนเดิมไมเปลี่ยนแปลง ไมวาจะเปนเรื่องรูปลักษณที่ปรากฏ หรือรสชาติของมัน)

ดังน้ัน คําวา part ของระบบ OpenDoc จึงไมเพียงแตจะหมายถึงพื้นที่ซึ่งแตละออพเจ็คท

ครอบครองอยูเทาน้ัน แตยังหมายถึงพื้นที่ของออพเจ็คทที่ฝงตัวอยูในอีกออพเจ็คทหน่ึงอีกดวย โดยแตละ part ก็ตาง

มีโปรแกรม editor ของตนเอง ถึงแมวาจะประกอบอยูภายในหนาตางเดียวกันบนหนาจอคอมพิวเตอร (same

window), อยูในไฟลลขอมูลไฟลลเดียวกัน

(same file) และถูกจัดเก็บไวในหนวยความจํา

สํารองเดียวกัน (same disk or same storage

server)

เวลาที่ผูใชคอมพิวเตอรทําการ

ดัดแปลงแกไขขอมูลตางๆ ภายในเอกสาร

Compound document เหลาโปรแกรม

4

editor ซึ่งทําหนาที่รับผิดชอบออพเจ็คทแตละออพเจ็คทอยูก็จะถูกเปดข้ึนมาทํางานรวมกันไป โดยการทํางาน

พื้นฐาน (basic task) ของโปรแกรม editor เหลาน้ี ประกอบไปดวย การจัดเก็บขอมูลในออพเจ็คทเขาไวในดิสกใน

กรณีที่จําเปน, จัดสรางภาพรายละเอียดของออพเจ็คทข้ึนบนหนาจอมอนิเตอร หรือสงผานรายละเอียดดังกลาวไปยัง

เครื่องพิมพในกรณีที่มีการสั่งพิมพงาน, และตอบสนองตอการทํางานตางๆ บนออพเจ็คทที่ผูใชคอมพิวเตอรสั่งผานทาง

เมาส หรือคียบอรด

ซี่งในสวนของการตอบสนองของโปรแกรม editor ที่มีตอการคลื้กเมาสหรือกดแปนคียบอรดน้ัน

จําเปนอยางมากที่จะตองอาศัยการจัดแบง part ที่ถูกตองชัดเจนบนเอกสาร Compound document ดวยกลุมของ

การทํางานคลังขอมูล libraries ทําใหระบบ OpenDoc มีขอดีเหนือกวาระบบ Object-oriented programing อื่นๆ

เพราะมิไดมีการอางอิงถึงระบบด้ังเดิม (extended through inheritance) ซึ่งจัดสรางแตละออพเจ็คทข้ึนมาเลย

ระบบ OpenDoc เพียงแตนําเอาออพเจ็คทแตละ part เขามาประกอบไวดวยกันภายในเอกสาร

Compound document เทาน้ัน จึงสามารถประกอบเอาออพเจ็คทจากโปรแกรมประยุกตตางระบบเขามาไว

ภายในเอกสารเดียวกันได โดยไมจํากัดวาออพเจ็คทดังกลาวน้ันจะถูกสรางข้ึนเพื่อระบบปฏิบัติการใด หรือถูกสราง

บนแพล็ตฟอรมคอมพิวเตอรประเภทไหน เวลาที่มีการสรางเอกสาร Compound document สิ่งที่กลุมการทํางาน

libraries ทําก็มีแคเพียงการอางถึงรหัส procedure code ในกรณีที่จําเปน

องคประกอบสําคัญของ OpenDoc

ระบบ OpenDoc ประกอบไปดวยการทํางานสําคัญๆ หลายชนิดที่ถูกใชเพื่อการจัดวางองคประกอบ

ตางๆ ภายในเอกสาร Compound document และการเรียกคนขอมูลองคประกอบเหลาน้ัน เริ่มดวยการทํางาน

OpenDoc's layout system ซึ่งทําหนาที่ชวยเหลือสนับสนุนหาขอตกลงในการกําหนดตําแหนงเลยเอาท (layout

negotiation help) ของแตละ part บนเอกสาร เพื่อวาจะไดไมมีการวางสวนของ part ซอนกันระหวางออพเจ็คท

การทํางาน OpenDoc's layout system ยังเปนตัวกําหนดวาโปรแกรม editor ใดควรจะถูก

เรียกข้ึนมาทํางาน เมื่อมีการคลื้กเมาสบนหนาจอมอนิเตอรอีกดวย โดยมันไมเพียงแตจะรับรูถึงตําแหนงของออพ

เจ็คท และตัวช้ีของเมาสบนหนาตางที่ปรากฏบนจอมอนิเตอร (on-screen windows) เทาน้ัน แตยังครอบคลุมไปถึง

ภาพซึ่งไมปรากฏบนหนาจอมอนิเตอร (off-screen bit maps) อีกดวย นอกจากน้ันการทํางาน OpenDoc's

layout system ก็ยังมีสวนรับผิดชอบตอภาพกราฟฟกชนิด 2 มิติ และ 3 มิติ ที่ซอนทับกันอยู และการอัพเดทแตละ

สวนของเอกสารที่กําลังใชงานอยูไปพรอมๆ กันดวย (simutaneous active parts updateing)

การทํางานที่นาสนใจ

ถัดมาของ OpenDoc คือ การทํางาน

"event-dispatching system" ซึ่งทํา

หนาที่กําหนดเสนทาง (routing) ของ

การดําเนินการตางๆ ที่ผูใช

คอมพิวเตอรเรียกใชใหถุกสงตรงไปยัง

5

สวนของ part ที่ผูใชตองการไดอยางถูกตองหมาะสมโดยอาศัยความชวยเหลือจากการทํางาน layout system ทํา

ใหผูใชคอมพิวเตอรสามารถเขาถึงสวน part ของเอกสารที่ตนตองการไดโดยตรง โดยไมจําเปนตองกดคลิ้กเมาสซอน

กันสองครั้ง (double click) หรือเรียกผานเมนูคําสั่งใหยุงยากวุนวาย

ตอจากการทํางาน event-dispatching system ก็คือการทํางาน OpenDoc's storage system

ซึ่งชวยใหสวน part ตางๆ ของเอกสาร Compound document สามารถจัดเก็บบันทึกขอมูลที่สลับซับซอนอยาง

มากน้ันไวภายในไฟลลสวนกลาง (shared file) ไดอยางถูกตอง รวมทั้งยังสามารถจัดเก็บแบบรางเอกสารทีละหลาย

เอกสาร (multiple document drafts storing) และจัดเก็บขอมูลความสัมพันธระหวาง part ที่ถูกฝงตัวไวภายใน

อีก part หน่ึง (embedding information) ไดดวย

นอกจากน้ัน ระบบ OpenDoc ยังประกอบดวยการทํางาน data transfer system ซึ่งชวยจัดสง

ขอมูลจาก part หน่ึงของเอกสาร ไปยังอีก part หน่ึงของเอกสาร (part information shipment) ใหเปนไปอยาง

ถูกตองเหมาะสม ซึ่งขอมูลที่ถุกจัดสงน้ีหมายรวมไปถึงขอมูล embeded information ที่ถูกฝงตัวอยูใน part อื่น

ดวย การสงผานขอมูล embeded information น้ัน อาจจะโดยผานทางการทํางาน clipboard ของวินโดวส, โดย

วิธีการสรางความเช่ือมโยง (linking) ระหวาง part, หรือโดยการคลิ้กเมาสลากเอาขอมูลที่ตองการเคลื่อนยายไปวางที่

ตําแหนงซึ่งผูใชคอมพิวเตอรตองการ (drag-and drop) ก็ยอมไดทั้งสิ้น

สําหรับองคประกอบการทํางานสุดทายภายในระบบ OpenDoc ก็คือ "scripting system" ซึ่ง

อนุญาตใหผูใชคอมพิวเตอรทําการเช่ือมโยงการทํางานของแตละโปรแกรม editor ซึ่งรับผิดชอบแตละ part ภายใน

เอกสารเขาดวยกันไวไดอยางงายๆ ไมวาความสัมพันธดังกลาวน้ันจะเปนความสัมพัฯธภายในตัวเอกสารเดียวกัน,

ความสัมพันธภายในเครือขายเน็ตเวิรก หรือความสัมพันธระหวางแพล็ตฟอรมที่แตกตางกัน

OpenDoc

ความโดดเดนของระบบ OpenDoc น้ันอยูตรงที่มันเปนโครงสรางทางสถาปตยที่คาบเกี่ยวระหวาง

คอมพิวเตอรตางระบบ (cross-platform architecture) สามารถรองรับการทํางานของโปรแกรมประยุกตที่ถุกออก

แบบมาใหทํางานตางระบบกันได และรวมทั้งยังมีความสามารถในการจัดการกับกระบวนการการทํางานภายใตเอนวิ

รอนเมนท GUI environments ที่แตกตางกันไปไดอยางไมจํากัดอีกดวย

ที่วามันสามารถตอบสนองตอการทํางานภายใต GUI envirinemnt ที่ตางๆ กันไปน้ัน ก็เชนถาเปน

เอนไวรอนเมนท X Window System มันก็จะตอบสนองตอการกดคียบอรดดวยการเรียกไปที่ตําแหนงการทํางานบน

หนาตางที่เคอรเซอรกําลังวางอยู, แตถาเปนเอนไวรอนเมนทของ Macintosh มันก็จะตอบสนองตอการกดคียบอรืด

ดวยการเรียกไปที่หนาตางที่อยูบนสุด (frontmost window) พรอมกับเรียกไปที่บริเวณซึ่ง insertion point วาง

แทรกอยู

สําหรับในเอนไวรอนเมนทอื่นๆ ระบบ OpenDoc ก็จะมีรูปแบบการตอบสนองตอการคลิ้กเมาส

หรือกดคียบอรดแตกตางกันไปตามความเหมาะสม เรียกไดวาระบบ OpenDoc น้ันมีความยืดหยุนอยางมากตอการ

ตอบสนองผูใชในแตละสวน part ของเอกสาร ข้ึนอยูกับวาผูใชกําลังติดตอกับรูปแบบเอนไวรอนเมนทอะไรอยู และ

6

ความยืดหยุนดังกลาวน้ียังครอบคลุมลงมาถึงการทํางานตางๆ ภายในเอกสารอีกดวย โดย OpenDoc จะติดตอกับ

ผูใชคอมพิวเตอรดวยรูปแบบที่ตางๆ กันออกไปข้ึนอยูกับวาการติดตอน้ันๆ เปนการเรียกใชเมนูคําสั่ง, หนาตาง, คลิป

บอรด, หรือชองไดอะล็อกซ บ็อกซ ฯลฯ

อยางไรก็ตาม ความพยายามในการคงรูปแบบการติดตอกับผูใช (human interface

environment)ไวในรูปแบบใดรูปแบบหน่ึงซึ่งผูใชคอมพิวเตอรสามารถทําความเขาใจ และคุนเคยไดโดยงาย แมวาจะ

มีการติดตอกับแพล็ตฟอรมตางระบบกันน้ัน ไดนํามาซึ่งความยากลําบากเปนอยางมากในการออกแบบใหกับทีมงาน

ผูผลิตระบบ OpenDoc ทางออกของปญหาดังกลาวมีอยูสองทาง ทางแรก คือ ใชวิธีการติดตอกับผูใชแบบ

ผสมผสานระหวางรูปแบบที่ใชบนหลายๆ แพล็ตฟอรมรวมกันไปเลย (collection of each platform) สวนทางออก

ที่สอง ก็โดยการหาขอสรุปจากปญหาตางๆ ที่ผูใชอาจจะตองประสบแลวสรางเปนรูปแบบการติดตอใหมที่สามารถเขา

ไดกับแพล็ตฟอรมแตละแพล็ตฟอรม

และทางออกที่สองน่ีเองที่ถูกทีมงานผูออกแบบระบบ OpenDoc เลือกนํามาใชกับระบบของตน

ดวยการจัดสรางการทํางานหลักข้ึนมาสองอยาง คือ Dispatcher และ Arbritator โดย Dispatcher น้ันเปนออพ

เจ็คทซึ่งทําหนาที่ชวยเหลือสวนการทํางาน Dispatcher* ของระบบปฏิบัติการที่กําลังทํางานอยูในขณะน้ัน

(underlying platform) ในการคนหาโปรแกรม editor ที่เหมาะสมใหกับสวนของเอกสารที่ถูกเรียกใช

ในขณะที่สวน Arbitrator จะเปนวิถีทางสําหรับสวน part ตางๆ ของเอกสารใชในการระบุให

โปรแกรม Dispatcher ทราบวาโปรแกรม editor ใดเปนผูรับผิดชอบตอสัญญาณคียขอมูลที่ถูกปอนผานเขามาทาง

คียบอรด หรือแถบเมนูคําสั่งโดยผูใชคอมพิวเตอร และดวยการทํางานที่ผสมผสานกันระหวาง Dispatcher และ

Arbitrator น่ีเองที่เปนหลักสําคัญอันทําใหระบบ OpenDoc สามารถทํางานรวมกับรูปแบบการติดตอกับผูใชซึ่ง

แตกตางกันอยางมากระหวางแพล็ตฟอรมคอมพิวเตอรตางระบบได

การที่บอกวา Arbitrator เปนวิถีทาง (way) สําหรับ part ในการติดตอกับสวน Dispatcher อาจจะ

ไมถูกตองเสียทีเดียวนัก อันที่จริงแลว สวน Arbitrator เปนเพียงตาราง (table) ที่แสดงใหระบบ OpenDoc

ทราบวามีทรัพยากรใดถูกครอบครองอยูโดย part ใดบางในช่ัวขณะหน่ึง โดย Arbitrator จะรับรูถึงทรัพยากรตางๆ

ภายในระบบคอมพิวเตอรในสถานะที่เปน focus หน่ึงๆ เวลาที่มีการเรียกใชงาน part ของเอกสารแตละครั้ง สวน

Arbitrator ก็จะตอบสนองดวยการเปดเอากลุมของ focus ตางๆ ที่สัมพันธกันข้ึนมา

ซึ่งข้ันตอนการเปดเอาทรัพยากรตางๆ ในรูปของ focus ออกมาโดย Arbitrator น้ันจะประกอบไป

ดวยการทํางานสองชวงดวยกัน (two-phase commit mechanism) ชวงแรกเริ่มดวยการที่ Arbitrator รองขอตอ

part ตางๆ ที่กําลังครอบครองทรัพยากรอยูสละสิทธิในการครอบครองเสียกอน(ownership giveup) แลวจึงคอย

กําหนดสิทธิในการครอบครองทรัพยากรใหกับผูครอบครองใหมในชวงถัดมา (ownership reassign)

ประโยชนที่เห็นไดชัดเจนของการจัดแบงสิทธิในการครอบครองทรัพยากรสวนกลางในระบบของ

Arbitrator ก็ไดแก การที่โปรแกรม editor ของ part หน่ึงกําลังครอบครองสิทธิในสวนของเมนูบารอยู พรอมๆ กับ

ที่โปรแกรม editor ของอีก part หน่ึงก็กําลังครอบครองสิทธิในสวนของการกดแปนคียบอรดอยู หากแตละ

โปรแกรม editor ตางก็ตองการจะใชสิทธิในสวนของทรัพยากรที่อีกโปรแกรม editor กําลังครอบครองอยู โดยไม

7

ยอมยกเลิกสิทธิครอบครองของอีกฝายหน่ึงเสียกอนแลวละก็ ระบบคอมพิวเตอรคงตองเกิดสภาวะการแฮงค

(deadlock) ไมสามารถทํางานตอไปไดอยางแนนอน

รูปแบบการทํางานผสมผสานกันระหวาง Dispatcher และ Arbitrator ของระบบ OpenDoc ที่

กลาวผานมาน้ี สําหรับผูอานที่คุนเคยอยูกับการประมวลผลในระบบเครือขายเน็ตเวิรก (network) หรือการ

ประมวลผลหลายหนวยประมวลผล (multiprocessing) คงจะไมรูสึกวามันแปลกใหมนาสนใจสักเทาใดนัก เพราะ

มันก็คลายๆ กับเทคนิคที่ใชปองกันการแฮงคของระบบอันเน่ืองจากการแยงใชทรัพยากร (deadlock involving

resource) ซึ่งเปนที่รูจักกันทั่วไปอยูแลวน่ันเอง

แตที่สวน Arbitrator ของระบบ OpenDoc มีเหนือกวาการจัดแบงทรัพยากรอื่นๆ เห็นจะอยูตรงที่

มันถูกออกแบบใหสามารถขยายขอบขีดความสามารถข้ึนไปได (extensibility) ทําใหสามารถรองรับการทํางานของ

อุปกรณฮารดแวร หรือโปรแกรมประยุกตรูปแบบใหมที่จะถูกเสริมเขามาไดอยางไมจํากัด เวลาที่จะมีการเสริม

Arbitrator focus ใหมๆ เขามาภายในระบบ OpenDoc ก็เพียงแตจัดสรางอ็อพเจ็คทใหมข้ึนมาในช่ือ focus

module เพื่อเสริมเพิ่มเขาไปในสวน Arbitratorที่มีอยูเดิมในระบบ OpenDoc ไดเลย

ยอนกลับมาพูดเรื่องการตอบสนองตอสัญญาณอินพุทที่ผูใชคอมพิวเตอรปอนเขามาอีกทีหน่ึง ปรกติ

ในระบบปฏิบัติการสมัยใหมทั่วไปที่ติดตอกับผูใชผานหนาตาง (windows) จะสงสัญญาณที่อินพุทที่ผูใชปอนเขามาไป

ยังหนาตางที่เปดอยูโดยตรงเลย แตสําหรับระบบ OpenDoc ที่แตละหนาตางประกอบไปดวยหลายๆ part แลว

จําเปนตองมีการจัดสงสัญญาณอินพุทไปยัง part ที่เหมาะสมเพิ่มข้ึนมาอีกข้ันตอนหน่ึงหลังจากที่ระบบจัดสงสัญญาณ

อินพุทไปยังหนาตางแลว ซึ่งหนาที่ในการจัดสงสัญญาณอินพุทไปยังสวน part ที่เหมาะสมภายในระบบ OpenDoc

น้ัน ก็คือหนาที่โดยตรงของการทํางาน Dispatcher น่ันเอง

และสําหรับที่บางระบบปฏิบัติการที่จําเปนตองมีการเช่ือมโยงระหวางหนาตางๆ หลายหนาตางเขา

ดวยกันเปน nested windows เพื่อใชกับงานประมวลผลที่มีการฝงตัวของออพเจ็คทภายในเอกสาร ระบบ

OpenDoc ก็จําเปนตองใชระบบเลยเอาทแบบ frame ที่มีความสลับซับซอนข้ึนเพื่อรองรับการทํางานดังกลาว โดย

การทํางาน frame น้ันจะจัดแบงสวนตางๆ ภายในหนาตางออกเปนพื้นที่ยอยๆ แยกจากกัน ทําใหระบบ OpenDoc

สามารถรองรับการประมวลผลประเภทที่มีการใชพื้นที่บางสวนของหนาตางซอนทับกัน (เชน การทํางานในระบบ

มัลติมีเดีย) ไดอยางไมมีปญหา

สวนของระบบ OpenDoc ที่ดูเหมือนจะไดรับความสนใจเปนพิเศษสําหรับผูคนในวงการ

คอมพิวเตอรน้ันเห็นจะไดแกวิธีการที่ OpenDoc ใชในการติดตอกับหนวยความจํา เพราะปจจุบันน้ีเรามีรูปแบบ

ฟอรแมทไฟลลที่ใชในการจัดเก็บขอมูลที่หลากหลายมากมายเสียเหลือเกิน แตละแพล็ตฟอรมคอมพิวเตอร และแต

ละประยุกตก็ตางลวนมีรูปแบบฟอรแมทที่จําเพาะตัวของตนเองดวยกันทั้งสิ้น จนแมกระทั่งในโปรแกรมประยุกต

ชนิดเดียวกัน หากถูกนําไปใชกับเครื่องคอมพิวเตอรตางระบบกันก็ยังมีการใชฟอรแมทของไฟลลแตกตางกันไปเลย

แนนอน การเลือกใชฟอรแมทของการจัดการกับหนวยความจําใหอยูในรูปแบบเดียวกันเสียหมดทุก

ระบบ ยอมจะนํามาซึ่งความสะดวกสบายสําหรับเหลาผูพัฒนาโปรแกรมประยุกตในการที่จะอัพเกรดเสริมรูปแบบ

การทํางานใหมๆ ใหกับการประมวลที่มีอยูเดิม แตในความเปนจริงแลว การเลือกใชรูปแบบฟอรแมทของไฟลลที่ใช

8

จัดเก็บขอมูลก็เปนเรื่องที่ไมสามารถกระทําไดอยางงายดายนัก จําเปนตองมีการช่ังนํ้าหนักระหวางผลดีผลเสียหลายๆ

อยางเขาดวยกัน

ผูพัฒนาโปรแกรมประยุกตจําตองตัดสินใจเลือกระหวางความเปนมาตรฐาน(standard) กับความ

เปนนวัตกรรม (innovation) ปญหาน้ีจะเกิดข้ึนเมื่อผูพัฒนาโปรแกรมตองการเสริมรูปแบบการทํางานชนิดใหมๆ

(new features) เพิ่มเขาไปในผลิตภัณฑโปรแกรมซอฟทแวรของตน แตในโปรแกรมเดิมก็มีรูปแบบฟอรแมทของ

ไฟลลที่แนนอนอยูแลว (หรือวาโปรแกรมประเภทเดียวกันน้ีที่มีจําหนายอยูในทองตลาดมีการใชรูปแบบฟอรแมทซึ่งมี

ลักษณะแนนอนอยูแลว)

ซึ่งถาผูพัฒนาโปรแกรมประยุกตทานน้ีมุงไปที่เนนเรื่องนวัตกรรมใหมเพียงอยางเดียว ก็คงนําเสนอ

การทํางานที่พัฒนาข้ึนมาใหมน้ันเขาสูตลาดไปเลย แตถาสนใจเรื่องาตรฐานก็คงตองใชเวลาดัดแปลงการทํางาน

ดังกลาวใหเขากันไดกับมาตรฐานที่มีอยูเดิมในทองตลาดเสียกอน และก็คงตองกินเวลานานพอสมควรเพราะรูปแบบ

ฟอรแมทไฟลลปรกติทั่วๆ ไปมักจะไมอนุญาตใหดัดแปลงเสริมแตงอะไรไดงายๆ

นอกจากน้ัน ผูพัฒนาโปรแกรมประยุกตยังตองตองตัดสินใจเลือกระหวางความสะดวกในการ

เผยแพร (publication) กับความ

มีประสิทธิภาพในการปรับปรุง

(efficiency editting) อีกดวย

ซึ่งเปนปญหาที่เกิดข้ึนเมื่อ

จําเปนตองนําเสนอไฟลลฟอรแมท

ในมาตรฐาน standard

interchange format ที่สามารถ

แลกเปลี่ยนระหวางระบบได

โดยปรกติรูปแบบฟอรแมทแบบ

interchange format น้ีมักจะถูกออกแบบใหมีลักษณะเปนกลางๆ ไมเขากับรูปแบบฟอรแมทใดฟอรแมทหน่ึงอยาง

แนนอนลงไป เพื่อใหงายสําหรับการอาน และการขยับขยายไปใชกับระบบฟอรแมทอื่นๆ

แตก็อีกน่ันแหละ ความสะดวกในการเผยแพรของรูปแบบฟอรแมทแบบ interchange format น้ัน

ตองแลกมาดวยการที่มันถูกออกแบบมาอยางครึ่งๆ กลางๆ ไมสามารถทําการดัดแปลงแกไขไดอยางมีประสิทธิภาพ

(unefficiency editting) หรือไมสามารถทํางานใหสมรรถนะประสิทธิภาพของมันบนคอมพิวเตอรบางระบบได (lack

of performance) ซึ่งทางออกสําหรับกรณีน้ีที่นิยมใชกันก็เห็นจะไดแกการที่ผูผลิตโปรแกรมประยุกตออกแบบ

ผลิตภัณฑของตนใหสามารถรองรับฟอรแมทของไฟลลไดหลายรูปแบบ แตเวลาจะทํางานตองมีการแปลงรูปแบบ

ฟอรแมทใหอยูในรูปแบบของตนเองเสียกอน (rewritten)

อยางไรก็ตาม การที่เอกสาร Compound document ประกอบไปดวยองคประกอบหลายๆ part

และแตละ part ก็ตางมีรูปแบบฟอรแมทของตนเอง ทําใหมันเปนเรื่องหลีกเลี่ยงไมไดเลยที่จะตองมีการใชรูปแบบ

ฟอรแมทของไฟลลมากกวาหน่ึงชนิดภายในเอกสาร และปญหาที่ตามมาก็คือ ฟอรแมทไฟลลเหลาน้ีมักจะผสมผสาน

9

กันไดไมคอยจะกลมกลืนนัก ระหวางไฟลลฟอรแมทประเภทที่งายตอการดัดแปลงแกไข (efficient editing) กับไฟลล

ฟอรแมทประเภทสะดวกตอการเผยแพร (efficient publication)

โดยไฟลลฟอรแมทที่งายตอการดัดแปลงแกไขน้ัน มักจะจะใชวิธีจัดการกับขอมูลทีละเปนกลุมๆ

(based on string of bytes) และสามารถเขาถึงกลุมขอมูลเหลาน้ีไดโดยวิธีสุม (Random access) ผานทางตาราง

ระบุตําแหนงขอมูล เพื่อวาจะสามารถดัดแปลงแกไขขอมูลภายในไฟลลไดอยางรวดเร็ว และมีประสิทธิภาพ แตก็

สงผลใหตองพึ่งพิงโปรแกรม editor เพื่อดัดแปลงแกไขขอมูลเหลาน้ีเปนการเฉพาะ

ในขณะที่ไฟลลฟอรแมทประเภทที่ออกแบบมาใหงายสําหรับการเผยแพร (efficient publication)

น้ัน มักจะใชวิธีติดตอกับขอมูลทีละไบททีละไบทเรียงกันไปตามลําดับเหมือนสายพานลําเลียง (stream oriented)

จึงงายสําหรับการรับรูโดยโปรแกรมประยุกตทั่วๆ ไป ดังน้ัน เมื่อจําเปนตองนําเอาไฟลลฟอรแมทแบบ efficient

publication ที่เขาถึงขอมูลตามลําดับ มาผสมผสานเขากับไฟลลฟอรแมท efficient editing ที่เขาถึงขอมูลอยางสุม

ทีละกลุมคํา จึงยอมนํามาซึ่งความสับสนของลําดับขอมูลอันมิอาจหลีกเลี่ยงได

เชน ถาเราพยายามสอดกลุมขอมูลของ efficient publication เขาไปในลําดับขอมูลของ efficient

editing จะเกิดขอขัดแยงอันไมสามารถยอมรับได (unacceptable constraint) วาจะเติมกลุมคําใหมเขามาเมื่อไหร

และอยางไร ในทางกลับกันการสอดขอมูลแบบเรียงตามลําดับของ efficient publication เขาไปในกลุมคําของ

efficient editing ปญหาก็จะอยูตรงที่วาควรจะสอดกลุมคําขนาดความยาวเทาไรดี และมันไมมีทางสอดเขาหรือดึง

กลับขอมูลเหลาน้ันไดอยางถูกตองเลยหากไมทราบถึงตารางกลุมขอมูล piece-table structure ของฟอรแมท

efficient editing ดังน้ัน เพื่อแกปญหาเรื่องความไมผสมผสานกลมกลืนระหวางไฟลลฟอรแมทดังกลาว ระบบ

OpenDoc จึงใชวิธีการเปดไฟลลช่ัวคราวในรูปฟอรแมท metafile ข้ึนมาเพื่อจัดเก็บไฟลลฟอรแมท efficient

publication และ efficient editing ไวดวยกัน

ถึงแมวาระบบ OpenDoc จะสามารถรองรับรูปแบบฟอแมทการจัดเก็บขอมูลที่แตกตางกันออกไป

ไดอยางหลากหลาย แตมันก็จําเปนตอง กําหนดคากําหนดระบุแพล็ตฟอรม

(platform implementation) สําหรับแตละ ฟอรแมทดวยการอางอิงถึงรูปแบบ

ฟอรแมท Bento อันเปนรูปแบบฟอรแมท สําหรับจัดเก็บขอมูลเอกสาร

Compound document ซึ่งไดรับการ พัฒนาข้ึนโดยบริษัท Appleโดยแบบ

ฟอรแมท Bento น้ีจะถุกออกแบบใหสามารถ จัดเก็บขอมูลตางฟอรแมทไดอยาง

หลากหลาย สามารถรองรับการทํางานแบบ มัลติมีเดียไดอยางมีประสิทธิภาพ อีก

ทั้งสามารถนําไปใชบนเครื่องคอมพิวเตอรตาง แพล็ตฟอรมไดอยางไมจํากัด

ผลจากการอางอิงถึงรูปแบบฟอรแมท Bento น้ัน ทําใหระบบ OpenDoc สามารถจัดการขอมูล

ภายในหนวยความจําไดโดยไมจําเปนตองคําน่ึงถึงวาขอมูลดังกลาวจะถูกจัดเก็บแบบเรียงลําดับ (sequential) หรือถูก

จัดไวเปนกลุมๆ (piece-based) รวมทั้งยังไมตองใสใจวาการเขาถึงขอมูลดังกลาวน้ันจะเปนไปในแบบสุม (random

access) หรือเปนไปแบบตามลําดับ (sequential access)

10

ในการอธิบายถึงรูปแบบการจัดการกับหนวยความจําของระบบ OpenDoc น้ัน จําเปนตอง

เปรียบเทียบกับแบบจําลองหนวยความจํา (OpenDoc's storage model) อันประกอบไปดวยพื้นที่ขอบเขตการ

จัดเก็บขอมูลพื้นฐานที่มีช่ือเรียกวา "value" ซึ่งถูกรับรูโดยโปรแกรม editor คลายกับวาเปนไฟลล ไฟลลหน่ึง

สามารถอาน, บันทึก, หรือเรียกคนโปรแกรมภายในข้ึนมาทํางานได ไมตางไปจากไฟลลปรกติทั่วๆ ไป

นอกจากสวนของ Value ข้ึนมา แบบจําลองระบบ OpenDoc ก็ยังมีการรองรับสองคําสั่ง

ดําเนินการสําคัญซึ่งกระทําตอขอมูลภายในหนวยความจําอีกดวย สองคําสั่งที่วาน้ันคือ "คําสั่งลบขอมูล (delete)"

และ "คําสั่งสอดแทรกขอมูล (insert)" โดยการทํางานทั้งสองอยางน้ีเมื่อเกิดข้ึนบนแบบจําลองระบบ OpenDoc จะ

มิไดมีการลบ หรือสอดแทรกขอมูลเขาไปภายในลําดับขอมูลซึ่งอยูในสวน value จริงๆ ไมมีการก็อปปขอมูลจํานวน

มากมายภายใน value ไปมาใหสับสน

คําสั่ง delete และ insert ในระบบ OpenDoc เพียงแตใชวิธีการจัดการกับตาราง table of

content ซึ่งระบุตําแหนงของขอมูลที่ถูกสับเปลี่ยนไปเทาน้ัน สวนของขอมูลที่ถุกบันทึกอยูในหนวยความจํายังคงอยู

ในตําแหนงเดิมที่มันอยู เหมือนเดิมทุกประการ ดังน้ัน ไมวาจะเปนการสอดแทรกขอมูลฟอรแมท sequential

format หรือ piece-based format เขามาภายในกลลุมขอมูลเดิม ก็ตางลวนไมทําใหเกิดปญหากับหนวยความจํา

เดิมแตอยางไร เพราะการสอดแทรกน้ันเกิดข้ึนในระดับตารางระบุตําแหนงเทาน้ัน มิไดเกิดข้ึนบนลําดับจริงของ

ขอมูล

ในหนวยความจําของระบบ OpenDoc น้ัน จะประกอบไปดวย value หลายๆ value และมีการ

จัดเก็บ value เหลาน้ีไวเปนกลุมๆ ในอ็อพเจ็คทที่เรียกวา "storage unit" ซึ่งแตละ part บนเอกสารของ OpenDoc

ก็จะมีหนวย stroge unit จําเพาะตัวของตนเอง อันประกอบไปดวยลิสตรายการระบุชนิด และรายละเอียดของ Valu

(list of named properties) ที่จัดเก็บอยูภายใน storage unit น้ันๆ วามีอะไรบาง จะวาไปแลว storage unit ก็

คลายๆ กับไดเร็กตอรี่ในระบบ DOS และ Windows น่ันเอง

แตที่ตางไปจากไดเรกตอรี่ทั่วๆ ไปน้ัน อยูที่ Storage unit ของระบบ OpenDoc สามารถจัดเก็บ

ขอมูลหลายๆ ฟอรแมทไวภายใน value เดียวกันได ในขณะที่ในระบบไฟลลของ DOS หรือ Windows น้ันจะ

สามารถจัดเก็บไวดวยขอมูลฟอรเดียวเทาน้ัน ทําใหการจัดการขอมูลในหนวยความจําแบบ storage unit ของระบบ

OpenDoc มีความเหมาะสมอยางมากสําหรับรองรับการทํางานแบบเอกสาร Compound document ที่มีหลายๆ

part ประกอบเขาดวยกัน และทําใหโปรแกรม editor ที่รับผิดชอบแตละ part บนเอกสารจัดการแกไขดัดแปลง

หรือจัดเก็บขอมูลบน part

ไวภายใตช่ือเดียวกันได

โครงสราง

การจัดเก็บขอมูลใน

หนวยความจําของระบบ

OpenDoc ที่ถัดจากสวน

storage unit ข้ึนมาก็คือ

11

สวนที่มีช่ือเรียกวา "draft" ซึ่งเปนลิสตรายการของ storage unit หลายๆ หนวยประกอบเขาดวยกัน โดยขอมูลใน

draft น้ีจะมิใชคาตายตัวของขอมูลในเอกสาร Compound document แตจะเปนคาในช่ัวขณะ (snapshot state)

หรือพูดงายๆ ก็คือเปนแบบรางซึ่งสามารถเรียกกลับมาดูไดในภายหลัง ถึงแมวาตัวเอกสารจริงๆ จะมีการ

เปลี่ยนแปลงแกไขใหตางไปจากเดิมแลว ทําใหการทํางานของ OpenDoc เปนไปไดอยางมีประสิทธิภาพ เพราะไมวา

จะมีคําสั่งดําเนินการอะไรติดตามมา (คําสั่งที่วาอาจจะเปน insert, delete, read, write etc.) การดําเนินการที่

เกิดข้ึนจริงก็เพียงแตเปลี่ยนแปลงจากคา draft สุดทายเทาน้ัน

ความโดดเดนเปนพิเศษของการจัดเก็บขอมูลเอกสารไวในรูป draft น้ัน อยูตรงที่มันอนุญาตให

values ที่จัดเก็บอยูภายในสามารถอางอิงถึง storge units ตางๆ ในหนวยความจําไดโดยมิไดจํากัดวาโครงสรางการ

จัดเก็บหนวยความจําน้ันจะมีความสลับซับซอนใหญโตเพียงไรและ value ในหนวย storage หน่ึงสามารถอางอิงถึง

storage unit อื่นๆ ใน draft เดียวกันไดอยางอิสระ

และดวยการอางถึงกันไดอยางอิสระระหวาง value และ storage unit น้ีเอง ก็ทําใหโครงสราง

แบบ Draft ของระบบ OpenDoc สามารถรองรับการจัดโครงสรางภายในหนวยความจําไดสารพัด ไมวาจะเปน

โครงสรางงายๆ ที่มีการแตกสาขาไมมาก ไปจนกระทั่งโครงสรางแบบ hypertext ที่มีการอางถึงขอมูลใน

หนวยความจําอื่นๆ อยางสลับซับซอน (ไมเหมือนการจัดการหนวยความจําแบบ DOS หรือ Windows ที่ถามีการอาง

ถึงไฟลลในไดเรกตอรี่ที่ไมมีการใส path หรือกําหนด registration ไวแลว อาจจะทําใหเครื่องแฮ็งคเอาไดงาย)

ทุกๆ โครงราง draft ของเอกสารจะมีสวนของ part ทําหนาที่เปนตัวช้ีตําแหนง (pointer) อยู

ตําแหนงบนสุดของเอกสารเรียกวา "root part" ซึ่งถูกใชเพื่อการเปดโครงราง draft ข้ึนปรากฏเปนหหนาตางบน

จอมอนิเตอร หรือเพื่อสั่งพิมพเอกสารออกทางเครื่องพิมพที่ตอพวงอยู ในขณะที่สวนของ part อื่นๆ ที่ถูกฝงตัวอยู

ในเอกสารจะถูกดําเนินการลักษณะดังกลาวผานทางกลไกการอางอิง (reference mechanism) ของระบบ

OpenDoc ทําใหเอกสารของ OpenDoc สามารถจัดโครงสรางตางๆ กันไปไดอยางมากมาย ข้ึนอยูกับสวน root

part ซึ่งเปน part หลักของเอกสารถุกกําหนดไวอยางไร

เชน ถาตัว root part ถูกกําหนดให

เปนโครงสรางแบบตารางสเปรดชีต สวนของ part

อื่นๆ ที่จะนํามาฝงตัวก็จะตองอยูบนตารางหลัก (main

sheet) เทาน้ัน แตถาตัว root part ถูกกําหนดดวย

Rolodex editor สวนของ part ที่จะนํามาฝงตัวก็

สามารถที่จะนําไปใสไวใน card ใดๆ กไดใน Rolodex

ฯลฯ (ขอมูลจาก part เดียวกันสามารถถูกนําไปฝง

ตัวไวในตําแหนงตางๆ กันไดโดยไมมีปญหา)

แบบจําลองระบบ OpenDoc ยังมีการจัดเอกสารที่ประกอบไปดวยลิสตรายการของ draft ลวนๆ

อีก ภายในเอกสาร darft ที่มีช่ือเรียกวา "current draft" ใชนําเสนอถึงสถานะลาสุดของเอกสาร (latetest state

document) อันเปนสิ่งที่ปรากฏสูสายตาผูใช OpenDoc เวลาที่มีการเปดเอกสารข้ึนมาดู และนับเปนรูปแบบการ

12

ทํางานซึ่งทําใหระบบ OpenDoc มีความโดดเดนเหนือกวาการประมวลผล Compound document อื่นๆ ที่เคยมีมา

ทั้งหมด ที่สําคัญ มันยังทําใหโปรแกรม editor ซึ่งรับผิดชอบ part บนเอกสาร สามารถใหความสําคัญกับการ

ดําเนินการสวน I/O operation ไดอยางเต็มที่โดยไมตองไมเสียเวลากับการดําเนินการอื่นๆ

ชุดคําสั่ง Scripting ของ OpenDoc

การออกแบบชุดคําสั่ง Scripting ของ OpenDoc น้ันเขาใจวามีจุดมุงหมายหลักอยูสองประการ

ดวยกัน อยางแรกคือมันจะตองเปนชุดคําสั่งที่มนุษยสามารถเขาใจไดโดยงาย (human interface) โดยเฉพาะผูใช

โปรแกรมทั่วๆ ไป ไมใชผูเช่ียวชาญ หรือโปรแกรมเมอรที่ตองรูจักภาษา C เปนอยางดีจึงจะสามารถใชได อยางที่

สอง ชุดคําสั่ง Scripting น้ันจะตองมุงเนนไปเพื่อการปฏิบัติงานใหบรรลุลวงถึงเปาหมายเปนสําคัญ โดยไมติดขัดวา

จะตองนําเอาการทํางานรูปแบบใดเขามาประกอบกับการดําเนินการบาง

อยางไรก็ตาม จุดมุงหมายทั้งสองประการน้ีมิใชสิ่งที่สามารถบรรลุไดอยางงายๆ เลย ลําพังแคที่วา

จะทําใหเปนชุดคําสั่งที่มนุษยสามารถเขาใจไดโดยงายก็เปนเรื่องมหาหินหนักหนาสาหัสอยูแลว เพราะปรกติแลว

ชุดคําสั่ง Scripting ของโปรแกรมประยุกตตางประเภทกันก็มักจะมีรูปแบบการทํางานพื้นฐานที่แตกตางกันไป มาก

บางนอยบาง

เชน ถาเปนชุดคําสั่ง Scripting สําหรับโปรแกรมประเภท Word processor วิธีการจัดเก็บขอมูล

ที่ดีที่สุดก็เห็นจะเปนการใสรหัสแบบ internally, run-length encoding น่ันเอง แตสําหรับการเขียนโปรแกรมดวย

ชุดคําสั่ง Scripting แลว ผูใชโปรแกรม Word processor คงจะไมคาดหวังวาตนเองจะตองติดตอเกี่ยวของกับการใส

รหัสแบบ run-length encoding ซึ่งคอนขางจะตองอาศัยความรูในเรื่องฮารดแวรอยางมากมาประกอบการทํางาน

ดวยเปนแน สิ่งที่ผูใช Word processor ตองการจากชุดคําสั่ง Scripting นาจะเปนเพียงคําสั่งงายๆ ที่เขาสามารถ

จะใชกําหนดรูปแบบเอกสาร, แบบตัวอักษร, ยอหนา ฯลฯ เทาน้ัน

สวนจุดมุงหมายประการสองของชุดคําสั่ง Scripting ที่เกี่ยวของกับการดําเนินการซึ่งมุงเนนที่

ผลสําเร็จเปนสําคัญน้ัน ก็เปนอีกเรื่อง

ที่ทีมผูออกแบบ OpenDoc ให

ความสําคัญไมดอยกวาเรื่องการติดตอ

ที่งายตอการเขาใจสําหรับผูใช

โปรแกรม เพราะตามปรกติแลวการ

ทํางานบนเอกสารของ OpenDoc

มักจะตองประกอบไปดวยกระบวนการ

ทํางานหลายๆ อยางบนรูปแบบ

ฟอรแมทขอมูลหลายๆ แบบ

ดังน้ัน หากตองการ

ใหชุดคําสั่ง Scripting สามารถทํางานไดบรรลุผลสําเร็จก็หมายความวาชุดคําสั่ง Scripting ของ OpenDoc จะตอง

13

สามารถติดตอกับกระบวนการทํางานที่แตกตางกันเหลาน้ันไดอยางถูกตองเหมาะสม และมีประสิทธิภาพ ซึ่งบางครั้ง

มิไดจํากัดอยูเฉพาะการติดตอกับ part หลายๆ part บนเอกสาร Compound document เดียวกันเทาน้ัน แตยัง

หมายรวมถึงการติดตอกับเอกสาร Compound document หลายๆ เอกสาร, การติดตอระหวางเครื่องคอมพิวเตอร

ตางระบบ, หรือจนกระทั่งการติดตอระหวางเครือขายเน็ตเวิรกที่ตางกันออกไปอีกดวย

การออกแบบชุดคําสั่ง Scripting ของ OpenDoc ใหบรรลุจุดมุงหมายหลักทั้งสองจึงนับไดวาเปน

เรื่องโหดมหาหินมิใชนอย และสําหรับทางออกของปญหาดังกลาวน้ี ทางทีมงานผูออกแบบ OpenDoc ตกลงใจที่ใช

โครงสรางทางสถาปตยแบบ OSA (Open Scripting Architecture) อันเปนโครง

สรางการจัดการกับชุดคําสั่ง Scripting บนเครื่องคอมพิวเตอร Macintosh ของบริษัท Apple เปนจุดต้ังตนสําหรับ

ชุดคําสั่ง Scripting ที่ตนจะพัฒนาตอไป

โครงสรางทางสถาปตยแบบ OSA น้ี ประกอบดวยโปรแกรม library ที่นาสนใจหลายๆ โปรแกรม

อยางเชนโปรแกรม Apple Events ที่อนุญาตใหโปรแกรมประยุกตตางๆ สามารถเรียก (call) เอาโปรแกรมประยุกต

อื่นๆข้ึนมาทํางานได โดยมิไดจํากัดวาอีกโปรแกรมประยุกตหน่ึงน้ันอยูบนเครื่องคอมพิวเตอรเครื่องเดียวกัน หรืออยู

บนเครื่องคอมพิวเตอรอื่นในเครือขายเน็ตเวิรกเดียวกัน ทําใหชุดคําสั่ง Scripting ของระบบ OSA สามารถเช่ือมโยง

การทํางานระหวางโปรแกรมประยุกตหลายๆ โปรแกรม และระหวางเครื่องคอมพิวเตอรหลายๆ ระบบ ใหทํางาน

ตอเน่ืองกันไปไดดวยการใชคําสั่ง scriopt เพียงคําสั่งเดียวเทาน้ัน

โปรแกรม library ที่นาสนใจอีกโปรแกรมของระบบ OSA ก็คือ โปรแกรม Apple Events Manager ซึ่งทํางาน

สนับสนุนโปรแกรม Apple Events และทําใหการเรียก (call making) หรือการตอบรับ (call recieving) ของ

โปรแกรมประยุกตตางๆ ดวย Apple Events เปนไปอยางสะดวกงายดายข้ึน

อีกทั้งยังมีโปรแกรม library ที่อนุญาตใหภาษาคําสั่ง Scripting สามารถเรียกชุดคําสั่ง Scripting ที่

ใชอกีภาษาข้ึนมาทํางานได และสงผลใหผูใชสามารถเสริมเอาชุดคําสั่ง Scripting อื่นๆ เขามาในโครงสราง OSA ที่

ตนใชอยูได (ตัวอยางที่ดีสําหรับโครงสรางทางสถาปตยแบบของชุดคําสั่ง Scripting คือ "OLE 2.0 automation

interface) และสามารถเรียกใชคําสั่ง script ในระบบ OSA ของตนผานทางชุดคําสั่ง

Scripting ซึ่งใชภาษาที่ compatible ได

สําหรับผูท่ีตองการรายละเอียดเพ่ิมเติม

ปจจุบันระบบ OpenDoc อันเปนมาตรฐานใหมสําหรับการ

ประมวลผลแบบ Compound document น้ีไดเริ่มการติดต้ังดําเนินการ และใชงาน

ไปบางแลว แตยังคงเปนไปเฉพาะกลุมผูพัฒนาระบบ (Alpha-testing) และเมื่อใดที่

ระบบดังกลาวสําเร็จเสร็จลงตามประสงค ทราบวาทางทีมงานผูพัฒนาระบบ

OpenDoc มีแผนที่จะเผยแพรผลงานของตน (source code ) โดยผานทางหนวยงาน

ซึ่งเปน กลางสําหรับเหลาบริษัทผูผลิตผลิตภัณฑ

คอมพิวเตอรทั่วไป น่ันคือ หนวยงาน CIL C I L 688 Fourth Ave.,

San Fransisco, CA 97118

(408) 974-6549

14

(Component Integration Labs) ซึ่งถาทานผูอานทานใดตองการรายละเอียดมากไปกวาที่นํามากลาวถึงใน

บทความน้ี ก็สามารถติดตอหนวยงาน CIL ไดโดยตรง ตามตําแหนงที่อยูขางลางน้ี :-