|
02 ASCII vs The Blob
+------+ +--------+ +--------------+
! OPEN !----! SOURCE !----! ARCHITECTURE !
+------+ +--------+ +--------------+
Is architecture becoming software?
Architecture is definitely becoming more software-intensive and in-turn software dependent.
The main difference resides in the production of a building compared to the production of software.
Architecture is contrsucted, built and assembled on site.
It must comply with the local code standards and the architect and the builder are liable for any potential damages that may occur.
Software is compiled, installed, configured and almost all software
venues claim no liability for anything that may happen while using
their software.
When it comes to the software used to develop architectural ideas,
unfortunately, much of it is not inteded for use within the field of
architecture. Architects must then misuse/abuse 3D animation programs
and such to get the desired results.
In response to the limitations of the form follows software product, the accpetance of open source can push the boundaries of what computer source means to an architecural project. What language is may be best used to decribe a space? What does the source of a CAD file look like anyhow? Since its not really in any human readable format, should it be? Could it be? What would the code mean to the architect anyhow? Should there be any stuctural honesty between the structure of the progamming elements of the digital file and the end design?
ASCII (American Standard Code for Information Interchange)
"The ASCII code was the first 8-bit standard code that let characters - letters,numbers, punctuation, and other symbols - be represented by the same 8-bits on many different kinds of computers. It is limitted to the alphabet popular at the time in the USA but was adopted internationally( see ISO_Latin_1). It is the code used on the Internet. " more from Dick Botting
Blobs
When working with related database management systems (RDBMS), blobs
(Binary Large Objects) are long strings of unstructured data used for storing data like word docs, images,
pdfs, mp3s and most images. Blobs are examples of
unstructured data and must be processed through some sort of client software to read any meaning out of them. When using Blobs in database the goal is to store and
organize this data. If the desire is to extract more sophisticated
information from the block of data, then Blobs will prove
difficult to work with.
Architecture of Variables in Blobs
Version Control
One of the great benefits of working with ASCII text files is the ability to work with a version control system.
+-------------+
Branch 1.2.2.3.2 -> ! 1.2.2.3.2.1 !
/ +-------------+
/
/
+---------+ +---------+ +---------+
Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
/ +---------+ +---------+ +---------+
/
/
+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
+-----+ +-----+ +-----+ +-----+ +-----+
!
!
! +---------+ +---------+ +---------+
Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
+---------+ +---------+ +---------+
While the need to manage binary files may seem obvious
if the files that you customarily work with are binary,
putting them into version control does present some
additional issues.
One basic function of version control is to show the
differences between two revisions. For example, if
someone else checked in a new version of a file, you
may wish to look at what they changed and determine
whether their changes are good. For text files,
CVS provides this functionality via the cvs
diff command. For binary files, it may be possible to
extract the two revisions and then compare them with a
tool external to CVS (for example, word processing
software often has such a feature). If there is no
such tool, one must track changes via other mechanisms,
such as urging people to write good log messages, and
hoping that the changes they actually made were the
changes that they intended to make.
Another ability of a version control system is the
ability to merge two revisions. For CVS this
happens in two contexts. The first is when users make
changes in separate working directories
(see section Multiple developers). The second is when one
merges explicitly with the `update -j' command
(see section Branching and merging).
In the case of text
files, CVS can merge changes made independently,
and signal a conflict if the changes conflict. With
binary files, the best that CVS can do is present
the two different copies of the file, and leave it to
the user to resolve the conflict. The user may choose
one copy or the other, or may run an external merge
tool which knows about that particular file format, if
one exists.
Note that having the user merge relies primarily on the
user to not accidentally omit some changes, and thus is
potentially error prone.
If this process is thought to be undesirable, the best
choice may be to avoid merging. To avoid the merges
that result from separate working directories, see the
discussion of reserved checkouts (file locking) in
section Multiple developers. To avoid the merges
resulting from branches, restrict use of branches.
|
