I'm going to try to describe an application using the thinobject scheme, a made-up but possibly useful application dealing with GPS data sets, i.e., files from and for storage on a hand-held gps.
The purpose of this exercise is really to present the thinobject system as an approach to doing something useful. For now, at least, this application is not going to be constructed.
This is just a sort of experiment.. you've been warned!
First, describe the problem domain:
A GPS unit stores location and time information, typically tagged with names given by the user, or automatically asigned by the device's firmware. The resulting files can be downloaded from or uploaded to the GPS device, and may represent potential places to visit or otherwise note, or may represent the actual locations visited, including detailed tracking data.
The goal will be to have a system capable of downloading data from a connected GPS -- or at least of storing the files so obtained -- and of viewing those data in different ways.
A GPS thinobject class should provide methods to do this sort of thing, so perhaps download() for a start.
(NOTE: I'll refer to methods using this functional notation, even though that may not be the form used in practice, in order to clarify the context.)
With the GPS class libraries in place, it should be sufficient to do:
<pre>
tob mygps.new GPS
</pre>
in order to create an object instance. Presumably there'd be some setup to support the interface to the gps unit, but this might be used:
<pre>
tob mygps.download ttyS0 9600
</pre>
The data files available in the gps unit are now represented in the object -- somehow. Now consider a couple of methods to use the data:
where the former method would be a text dump, and the latter would (somehow) generate output for display on a map.
I'm not going to worry, now, about details of how the data is stored. That's the application's business, as expressed in the behavior of the defined methods.
So far we have three methods identified, in download(), show-as-text(), and show-track-as-map(). These methods are really executable programs on the host operating system which comply with the command line interface structure:
<pre>
methodname objectpath [arguments]
</pre>
Each method might be written in any language, e.g., Perl, Ruby, shell, etc.; the thinobject system is independent of languages. However, there may be need for "helper" libraries in any given language to provide support for the basic features comprising the thinobject conventions.
A method may have no arguments, or may have many. Typically, a method will check for a set of option arguments before parsing "actual" arguments, but this is not dictated by the thinobject scheme.
These executable programs, with ownership and permissions as might be reasonable for the system, are stored in the GPS/ directory in the thinobject library root, e.g.,
Upon issuing the new() method, the named object will be created as a directory, and a symbolic link will be set to the GPS class library.
Now, the tob enabler can parse its command line to identify the object and method names, and then execute the method.
That's really the gist of this thing. The tob enabler parses the object and method, then looks in the object for the link to a thinobject class, checks for the method and then executes it.
Essentially the thinobject class link is a run-time executable path, explicitly managed as such by the tob enabler.
With an eye to security, the tob enabler will only follow class links if they point to an identified library root directory. Otherwise it might be possible to drop a trojan horse method somewhere and run it. The class library is presumed to have sufficient protection against this sort of thing.
When a method is executed, it first reads its target object as the first argument, then checks to ensure that the object is of the right class. (Note: this is something I've decided needs to be done, but I haven't actually done it yet...) The method will exit with an error if there's any problem.
... continued in another post...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm going to try to describe an application using the thinobject scheme, a made-up but possibly useful application dealing with GPS data sets, i.e., files from and for storage on a hand-held gps.
The purpose of this exercise is really to present the thinobject system as an approach to doing something useful. For now, at least, this application is not going to be constructed.
This is just a sort of experiment.. you've been warned!
First, describe the problem domain:
A GPS unit stores location and time information, typically tagged with names given by the user, or automatically asigned by the device's firmware. The resulting files can be downloaded from or uploaded to the GPS device, and may represent potential places to visit or otherwise note, or may represent the actual locations visited, including detailed tracking data.
The goal will be to have a system capable of downloading data from a connected GPS -- or at least of storing the files so obtained -- and of viewing those data in different ways.
A GPS thinobject class should provide methods to do this sort of thing, so perhaps download() for a start.
(NOTE: I'll refer to methods using this functional notation, even though that may not be the form used in practice, in order to clarify the context.)
With the GPS class libraries in place, it should be sufficient to do:
<pre>
tob mygps.new GPS
</pre>
in order to create an object instance. Presumably there'd be some setup to support the interface to the gps unit, but this might be used:
<pre>
tob mygps.download ttyS0 9600
</pre>
The data files available in the gps unit are now represented in the object -- somehow. Now consider a couple of methods to use the data:
<pre>
tob mygps.show-as-text
tob mygps.show-track-as-map \*
</pre>
where the former method would be a text dump, and the latter would (somehow) generate output for display on a map.
I'm not going to worry, now, about details of how the data is stored. That's the application's business, as expressed in the behavior of the defined methods.
So far we have three methods identified, in download(), show-as-text(), and show-track-as-map(). These methods are really executable programs on the host operating system which comply with the command line interface structure:
<pre>
methodname objectpath [arguments]
</pre>
Each method might be written in any language, e.g., Perl, Ruby, shell, etc.; the thinobject system is independent of languages. However, there may be need for "helper" libraries in any given language to provide support for the basic features comprising the thinobject conventions.
A method may have no arguments, or may have many. Typically, a method will check for a set of option arguments before parsing "actual" arguments, but this is not dictated by the thinobject scheme.
These executable programs, with ownership and permissions as might be reasonable for the system, are stored in the GPS/ directory in the thinobject library root, e.g.,
<pre>
/usr/local/lib/ThinObject/GPS/download
/usr/local/lib/ThinObject/GPS/show-as-text
/usr/local/lib/ThinObject/GPS/show-track-as-map
</pre>
Upon issuing the new() method, the named object will be created as a directory, and a symbolic link will be set to the GPS class library.
Now, the tob enabler can parse its command line to identify the object and method names, and then execute the method.
That's really the gist of this thing. The tob enabler parses the object and method, then looks in the object for the link to a thinobject class, checks for the method and then executes it.
Essentially the thinobject class link is a run-time executable path, explicitly managed as such by the tob enabler.
With an eye to security, the tob enabler will only follow class links if they point to an identified library root directory. Otherwise it might be possible to drop a trojan horse method somewhere and run it. The class library is presumed to have sufficient protection against this sort of thing.
When a method is executed, it first reads its target object as the first argument, then checks to ensure that the object is of the right class. (Note: this is something I've decided needs to be done, but I haven't actually done it yet...) The method will exit with an error if there's any problem.
... continued in another post...