Better archive

Okay, this is going to sound a bit harsh, I don't mean it that way. I'm just trying to open up some discussions about a belief which seems to be deeply held in some members of the Drupal community, and I fundamentally disagree with. I started a comment about the same on http://drupal.org/node/486558#comment-1685286.

What about looking into a tar and discovering its contents? What about adding files to an existing tar?

What about tarring strings instead of files?

What about the litany of options in Archive_Tar which just got zapped?

What about different archive compression format option?

What about the native php extensions the class seems to support?

I'm no lawyer, but I'm pretty sure if you rip out someone's code, and it has a license at the top, you will need to give credit at the very least.

Less lines of code does not mean it is easier to maintain or that it is any faster in any way that matters. I would suggest if you want to provide wrapper functions so Drupal developers don't need to learn an object interface, just instantiate the class as it is, and use it. Here's what will happen:

1. You will be able to maintain upstream patches from Archive_Tar
2. Other implementers will be able to harness the full spec of gnu tar as provided by Archive_Tar and not this very limited implementation OR they can use a simple adapter you provide.
3. The code base will increase a tiny bit.
4. I'm not 100% sure, but prove to me that this patch runs any faster than just using Archive_Tar. In an untarring operation, untarring and uncompressing accounts for about 99.9% of the load, the very simple object sitting around the operation takes the other .01%.
5. We don't focus on building things Drupal needs, we focus on re-writing something which has already been written and has proven to work fine; this wastes the amazing potential of great coders.
6. You can't test these two functions. All logic is encapsulated along with functionality. This is not unit testable. An object which separates the instantiation of variables, the control flow of operations and the actual destructive or constructive operations it preforms can be tested.

Again, I'm not being dogmatic and saying that it never makes sense to reduce the code base or simplify it. I'm just pointing out that there is a wealth of software out there, and instead of jumping to a "we can do it better" stance, it would be nice to see a "we can do it with you" attitude.

There are pros and cons to everything. For example, we've also had really bad experiences with including and relying on third-party libraries in the past. It was painful and expensive in its own way. On the other hand, we've been very happy with jQuery -- for the most part. Also, one doesn't exclude the other. One can have 2 basic functions in core, and contributed modules can still leverage a bigger library as needed. Lots of options exist and none of them is perfect.

This can't be changed for D7 now, and in D8 I guess the Archiver component can be easily extended/replaced.