Have you read the thread? Unlike you or taylor, we are not comfortable with the idea of using a proprietary archive format.
Yes, I did.
Having spent a few years watching taylor seem to do as much coding as the rest of the team combined I'm willing to believe that his design would have been well-designed and well-thought-out with regards to its application to the FS2Open engine. I see the beginnings of an idea here, but I don't see any kind of in-depth plan. I don't see anybody addressing his comment that the FS2Open CRCs are different than normal CRCs and you'd have to break the networking code to fix it, or addressing what level of compression is adequate, or whether third-party utilities would only compress the files that we want compressed. In fact, I see very little discussion or understanding of how this will work in the FS2Open engine. Will decompression be streamed for certain filetypes and not others? Which filetypes? Will the new pack files be read with the same precedence as old files? Will loading a 7z file be internally compatible with the structures that FS2Open uses to store package filesystem data?
Maybe those aren't issues now. Maybe you've rewritten the network code and the packfile code so it bears no resemblance to the old stuff and the time taylor spent researching this stuff is completely irrelevant now. I don't pretend to know.
A lot of these are issues that using a custom archive based on VPs can mitigate, but a standard archive format does raise. Sure, it's easier for users, and that's great (except where it's been pointed out that people might take that as license to edit them like archives).
I've spent probably a half-hour now reading this thread, digging up that post, and now tonight, explaining exactly how I can see it being useful. This didn't need to be a confrontation, I was trying to be helpful because I figured most people had probably not known or forgotten about that thread since it was so long ago and nobody had brought it up.
I didn't even state that I disagreed, and you're already arguing with me.
Yeah I'd imagine that was probably one of the reasons it was never implemented - no one had the time to sit down and write/maintain the code for the new format. Of course, no one's sitting down to get LZMA added in yet either, but maybe we can work on that shortly after 3.6.14.
This is the second needless assumption that pisses me off. Not only did I end up restructuring Maja in order to support compressed files, but I actually have a CVP handler in there with an 'import' function. An 'export' function is no big deal. I was considering doing that to ease the transition if that was what this discussion came to, but now I'm afraid to admit even thinking about volunteering for fear that you'll take it as further evidence that I think you're wrong and I'm trying to subvert your plans and fight you.
Trust me, if I seriously thought you should implement a proprietary format instead of 7-zip and I wanted to fight you on it, you would be looking at pages of writing explaining exactly how I thought your implementation was flawed, exactly why you shouldn't do it, how I could do better, and the plans I was already drawing up for my implementation. As it is, all I've done is repost (and now point out) a set of problems that somebody else spent time finding out, that now you (or whoever goes to do the implementation) doesn't have to spend time relearning or finding out when you make the change and the network code mysteriously quits working or something.
And where on earth did anybody get the impression that taylor endorses this or I even think taylor endorses this? The post was four years ago. A lot has changed since then in the computing world. I have no clue what taylor thinks and I am totally uncomfortable getting him involved in this now, for fear that somebody will think he has any opinion on this.TL,DR: Don't assume that people are fighting you and accuse them of doing no work on the subject when they're spending free time trying to help you.