The LINCKS GPD
In Linux Journal Issue 11, we described a typical installation of LINCKS, described the functionality of its components, and briefly introduced the main application interface, xlincks. Since LINCKS is distributed with an online tutorial, and a 70-page xlincks manual, we will assume that you know the basics about operating xlincks. In this second and last part, we describe how to create your own views, or general presentation descriptors (GPD), as we call them. For a reference manual description of GPDs, see chapter 7 of the xlincks User's Manual, and for a technical overview description see Journal of Systems and Software.
As a running example, we will show you how to use xlincks to create an address book, and the GPDs used to enter and display data. We start out by designing our data structures, then describe the LINCKS object model, and finally show how the address book is represented in the object model. We briefly describe the automatic search for GPDs used in xlincks and show our first GPD, followed by a description of the GPD's parts. We conclude by extending the newly-created GPDs to demonstrate a few additional features.
In our address book, the two obvious objects are the person object containing personal information, such as: name, birth date, e-mail address, and private phone number, and the address object. An address object can be shared by different persons and contains the common street address and common phone number.
In LINCKS, each object consists of the following parts:
IMAGE storing any type of information which can be PostScript, object code, a GIF, or a name (string). The size must be less than 232-1 bytes and the content is single-valued. (Currently, xlincks can only handle IMAGEs containing zero-terminated strings.)
ATTRIBUTE describing or typing the object. The value of an attribute is a zero-terminated string shorter than 216-1 bytes. An attribute is named by two strings, a group tag and a field tag, where several attributes can share the same group tag, but the combination of group and field must be unique.
LINKS containing links to other objects. A link field is plural, that is, for each object it can contain several links to other objects, as opposed to the attributes, which are single-valued.
In Figure 1, the window with three entries is the person object where the image contains the person's name, the second line specifies the birth date, and the fourth line is a link to an address object. The second, bigger window is the node view applied to the same object. (To apply another view, click on the item, then on the “Expand...” menu item, and then choose the node view. See the previous article in Issue 11, or read the xlincks manual, for more information.) The first entry in the node view is the image, followed by all the attributes and finally the link section beginning with the SYSTEM:Parent entry.
Notice that the system creates the two attributes SYSTEM:Created and SYSTEM:Owner--this pair is a good example of two attributes sharing the same group tag. In general we use all capital letters for the group part and lower case letters, possibly initial capital letters, for the field part.
GPDs are named by a string, which may contain white space. xlincks looks for a specific GPD first in your own GPDmaps and then in the list of system GPDmaps. This allows you to override the system GPDs with your own specialized GPDs. Now, if you expand the Empty User 4's GPDmap line, you will get a window with your first GPDmap as in Figure 2.
Replace the <<table>> with the name of the new GPD, person and then move out of the line with ctrl-n. A new placeholder <<gpd>> will appear which we fill in with a one line description of the new GPD, view of person object, as in Figure 3. Now, expand (meta-l meta-e) the description line to get the empty GPD template seen in the bottom of Figure 3.
First, you add a link from the GPDmap by first clicking on the line Empty User 4's GPDmap followed by a click on the line <<gpdmap>> in the empty GPD, then on the Add Link button—resulting in <<gdpmap>> being replaced with a link to Empty User 4's GPDmap.
Second, we need to define the logical structure by describing the logical parts in the person object. Earlier, we defined the person object to contain a name and birth date. Now, move to <<direct>> line in the STRUCTURE section and replace it with the name of our GPD, person. The name of the GPD used in GPDmap must occur at least once in the STRUCTURE part. After moving out of the line, we replace the newly created empty: value with the parts in our person object: name and “birth date”--since the part name includes a space we must use quotation marks (otherwise it would be three parts!).
Third, now that we've defined the structure of the person object, we need to define where to store the information. The ACCESS section of the GPD defines where we store or retrieve the parts of the logical structure. We would like to store the person's name in the IMAGE part and his/her birth date in an ATTRIBUTE called ADDRESSBOOK:Date.
To specify the name component, we move to the <<direct>> in the ACCESS section and replace it with the name (the name of structure part). Then we move out of the line and replace the empty: value with IMAGE. The resulting GPD can be seen in Figure 4. A warning: any omitted ACCESS specification defaults to IMAGE!
To define where we find the “birth date” in the ACCESS part we move the cursor to the name line in the ACCESS section and do an insert closest plural (meta-l meta-i), with the result as shown in Figure 5. Replacing the direct line with birth date (without quotation marks!) and the empty: value line with ATTR ADDRESSBOOK Date gives us Figure 6. Notice that we use the keyword ATTR followed by the group tag (ADDRESSBOOK) and the field tag to define the storage place for birth date in an attribute.
Last, if we would like to try our new GPD, we need to create a place to store the object, say in our LINCKS home directory:
1) Click on the line “Linux on the Road”
2) Do an insert closest plural (meta-l meta-i)
3) Expand the item (using meta-l meta-e or ctrl-left-click)
4) Fill in the GPD as person
5) Expand the same line (person) which should result in a two-line window saying item and empty: birth date as seen in Figure 7.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- Elliptic Curve Cryptography
- Getting Help With Linux
- Remote Compilation Using ssh and make
- Mediated Reality: University of Toronto RWM Project
- Writing Real-Time Device Drivers for Telecom Switches, Part 1
- NLE Video Editors
- Memory Leak Detection in Embedded Systems
- Linux Powers Four-Wall 3-D Display
- ViaVoice and XVoice: Providing Voice Recognition
20 min 32 sec ago
- Kernel Problem
10 hours 23 min ago
- BASH script to log IPs on public web server
14 hours 50 min ago
18 hours 26 min ago
- Reply to comment | Linux Journal
18 hours 58 min ago
- All the articles you talked
21 hours 22 min ago
- All the articles you talked
21 hours 25 min ago
- All the articles you talked
21 hours 26 min ago
1 day 1 hour ago
- Keeping track of IP address
1 day 3 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?