I've inspected a lot of issue tracking databases in the last few months - JIRA, Bugzilla, TeamTrack, ClearQuest, Trac, GNATS and Remedy1 - but the one I want to consider in this post is Remedy (a.k.a. the "Remedy Action Request System", part of BMC Remedy Service Management from BMC).
Remedy stores attached files in the database and compresses them to save space. That's fine, and they provide a compiled API library to talk to the running server application and extract and decompress the files. But if you're trying to get the data straight from the database, you're out of luck. Searching suggests that the file compression is some proprietary form of zlib but that's it. No source, no algorithm, nothing!
If you're providing an API to extract the data, why not show the customers the source? I suppose they might want to hide changes in the compression algorithm from users, but I can handle seeing that. I'm all for using carefully constructed APIs but not at the cost of the data being locked into one database.
1 I know, I know, you're thinking "wow, those toolsmiths sure do live life in the large!"
Tuesday, June 23, 2009
Remedy - free the attachments!
Posted by Matt Doar at 10:27 AM
Labels: bugs, remedy, software development
Subscribe to:
Post Comments (Atom)
2 comments:
Hi
I am looking at some traffice between a Remedy client and the application server.
Do you know if attachments remain compressed until they reach the client?
I ask as the data seems to be padded rather than compressed!
here is a sample of the hex dump from Wireshark
030 80 00 d1 d7 00 00 00 00 00 ac 00 00 00 b0 00 00 ........ ........
0040 00 b3 00 00 00 2d 00 00 00 b5 00 00 00 4f 00 00 .....-.. .....O..
0050 00 72 00 00 00 18 00 00 00 61 00 00 00 78 00 00 .r...... .a...x..
0060 00 3a 00 00 00 36 00 00 00 34 00 00 00 27 00 00 .:...6.. .4...'..
0070 00 5a 00 00 00 e9 00 00 00 33 00 00 00 81 00 00 .Z...... .3......
0080 00 20 00 00 00 ea 00 00 00 75 00 00 00 8b 00 00 . ...... .u......
0090 00 88 00 00 00 21 00 00 00 33 00 00 00 55 00 00 .....!.. .3...U..
00a0 00 2a 00 00 00 7d 00 00 00 ed 00 00 00 83 00 00 .*...}.. ........
00b0 00 18 00 00 00 6b 00 00 00 f0 00 00 00 0c 00 00 .....k.. ........
00c0 00 f9 00 00 00 0d 00 00 00 32 00 00 00 cf 00 00 ........ .2......
00d0 00 0e 00 00 00 49 00 00 00 8e 00 00 00 26 00 00 .....I.. .....&..
00e0 00 fa 00 00 00 ae 00 00 00 9c 00 00 00 f9 00 00 ........ ........
00f0 00 83 00 00 00 32 00 00 00 df 00 00 00 ab 00 00 .....2.. ........
0100 00 d9 00 00 00 33 00 00 00 d9 00 00 00 2a 00 00 .....3.. .....*..
0110 00 77 00 00 00 51 00 00 00 c1 00 00 00 e1 00 00 .w...Q.. ........
0120 00 9d 00 00 00 1d 00 00 00 66 00 00 00 54 00 00 ........ .f...T..
0130 00 99 00 00 00 32 00 00 00 f9 00 00 00 93 00 00 .....2.. ........
0140 00 fa 00 00 00 30 00 00 00 8b 00 00 00 57 00 00 .....0.. .....W..
0150 00 18 00 00 00 1f 00 00 00 d1 00 00 00 3f 00 00 ........ .....?..
0160 00 02 00 00 00 e4 00 00 00 6b 00 00 00 ea 00 00 ........ .k......
0170 00 44 00 00 00 cc 00 00 00 65 00 00 00 29 00 00 .D...... .e...)..
0180 00 1b 00 00 00 5b 00 00 00 2f 00 00 00 d6 00 00 .....[.. ./......
0190 00 0c 00 00 00 4a 00 00 00 71 00 00 00 fb 00 00 .....J.. .q......
01a0 00 74 00 00 00 77 00 00 00 54 00 00 00 7d 00 00 .t...w.. .T...}..
01b0 00 57 00 00 00 57 00 00 00 03 00 00 00 b8 00 00 .W...W.. ........
01c0 00 60 00 00 00 59 00 00 00 cc 00 00 00 de 00 00 .`...Y.. ........
01d0 00 c9 00 00 00 9d 00 00 00 81 00 00 00 b4 00 00 ........ ........
01e0 00 53 00 00 00 97 00 00 00 63 00 00 00 b8 00 00 .S...... .c......
01f0 00 03 00 00 00 08 00 00 00 86 00 00 00 49 00 00 ........ .....I..
02
I believe that the data has been uncompressed by the time it hits the wire.
Post a Comment