Ruminated Rumblings

RAID is a method that takes independent drives and lets a system group them together for security (redundancy or parity), speed enhancements, storage space increases or all three. One of the long-time stalwarts of the RAID environment is RAID 5. In RAID 5, you need at least 3 identically sized disks. They are combined so that the storage space is N-1 (i.e., in a 3-drive system, total space is 2x drive size). The last disk is used for parity. With a parity drive, you can remove any one of the drives and still have access to your data. If you remove two or more of the drives though, you'd better have a good backup. How does this work? Through the magic of XOR. The following statements are all true: A XOR B = PAR PAR XOR B = A A XOR PAR = B That's how parity lets you lose one disk and still recover your data. The same rules also apply in larger sets. Notice that you have to rotate the position of the parity data though. So a 5 drive system looks like: A XOR B XOR C ...

Nokia has announced that the new Qt library (4.5) will be available under the LGPL license (March 2009). Hopefully, this will mean that Embarcadero will revive Linux support with it's upcoming 64-bit, compile-to-many-targets compiler rewrite. Actually, it could mean that we would finally have a true CLX revision that would let us have native write-once, compile-to-many-targets, cross platform support for Windows, Mac, Linux, Embedded Linux, Windows CE, and the S60 (eventually). If Delphi's component architecture could be revamped to produce true Qt widgets, Embarcadero would suddenly enable all of the Delphi component vendors to gain access to a client-base that is much larger than what Delphi currently offers. Qt does not have much selection from third-party component vendors. A DevExpress or TMS Software offering would provide a nice upgrade to the basic Qt widgets. Delphi Prism theoretically supports multi-platform through the use of Mono but you have to add the managed cod...

In yet another stunning victory for Microsoft's cross-compatibility, their RTF system is incompatible between their own products. Let me begin by explaining that I have a Delphi app that uses a mail merge system to merge database text into a document. Naturally, you can do this a lot of different ways but, for my particular instance, I need to merge from a non-ODBC compliant database and then automatically E-mail the resulting document to the correct person. This is a management tool we use fairly heavily. In the past, I've always just used raw HTML formatting because it's handy and relatively standard. The particular request I've been working on is to format the resulting merge so that it can be printed in a "one summary page per item" format. HTML has the ability to do this with a style sheet as such: < STYLE TYPE ="text/css" > P.breakhere {page-break-before: always} </ STYLE > and use it via: < p class ="breakhere"...

A few weeks ago I started down the path of discovering how to GeoCode addresses for Delphi. This is related to a project we had where we wanted to show a map of a given point and then show facilities located near it on a map. I had originally started working with maps.live.com (which is a MS site). They have a decent little interface for JS that seemed to work for what I wanted AND I didn't have to store the annoying little GeoCoding addresses anywhere. This works great if all you want is a single address. For instance, the code below works for single addresses: < html > < head > < title > Address Lookup </ title > < meta http-equiv ="Content-Type" content ="text/html; charset=utf-8" > < script type ="text/javascript" src ="http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6" ></ script > <script type= "text/javascript" > var map = null ; ...

Serge Dosyukov recently posted about the speed of the Delphi installer. While I agree that it's annoying to have to wait for the initial installation, I find that one of the largest failures in most development environments (including Delphi) is uniformity in a group setting. For some reason, you can use products like subversion to manage your source code, but there is no product to standardize and manage your development environment. In our case, we have a handful of developers who all are working on different aspects of a large application (>1 million lines of code). We need to be able to manage the third-party add-ons and Delphi patches in a uniform way. The only method of doing this (to my knowledge) is to carefully install everything in the same paths and, usually, same order. At one point I thought we could be clever and tried to install all add-ons to a networked drive for every workstation to minimize the amount of thrash we encounter when installing SP for the add-ons....

I'm back to work on the HTTPS Post issue with DHL's ShipIt XML API. The problem I'm having is when I use Indy to post the xml via an HTTPS post, the response is that the file is malformed. I should mention that I'm using a relatively recent version of Indy 10. If I use FF (if you don't have it, check out the Poster add-on, let's you play with the HTTP functions using FF's libraries) it works fine. The first problem is that it's a little hard to see what FF is actually doing that is different from what Indy is doing. Enter Fiddler , stage right. Fiddler is an http proxy that captures that http information and lets you manipulate it or display the raw headers. So, pointing FF to the localhost proxy on port 8888, the headers I get are: POST /apilandingtest.asp HTTP/1.1 Host: ecommerce.airborne.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0...

If anyone has ever tried to get the OpenSSL libraries to work with Indy, you may have experienced a lot of pain with the process. I'm in the process of trying to develop an application for DHL's ShipIT XML Api that utilizes an HTTPS POST. The actual post code from Indy is easy response := HTTP.Post(url, file); but getting the SSL side to work, especial on Vista, is painful. I should disclose here that I have yet to get the HTTPS to send the data correctly via Indy, but I did finally get OpenSSL playing with Indy under Vista. Basically, the problem stems from the fact that Indy lets you make SSL assignments that will fail at run-time and then provides very little in the way of information about the failure. This is caused by IdSSLOpenSSLHeaders.pas not having any meaningful error reporting on the OpenSSL libraries failing to load. To be clear, it does basically say "Can't load library" but that's it. To fix it, search on SafeLoadLibrary in IdSSLOpenSSLHeaders.p...