<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
</div>OK, I'm spending a lot of time writing replies to you, and you're not<br>
reading the links I'm sending you. Please work harder if you want me<br>
to keep responding. Please search for 'MD5' in the spec and tell me<br>
what it says in the last hit. Thanks.</blockquote><div><br> Sorry, I missed that. I was misled by the use of the definite article in the sentence fragment "The corresponding signature file would be:"</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
> If all or most signatures have a special, one-to-one relationship with some<br>
> associated metadata, and in some cases cannot even be created by an activity<br>
> without Glucose adding that metadata, it seems to me there are several<br>
> reasons to prefer including such metadata in the same file or at least the<br>
> same directory. This is not possible with jar files, so any solution is more<br>
> or less a hack.<br>
<br>
</div>Your reasoning is poor. You are creating your own archive format<br>
because you don't want to create an extra file? Geez.</blockquote><div><br>I am creating my own archive format because the existing one solves essentially none of the problems I am interested in, and in fact makes it harder to solve them and less intuitive for others to understand the solutions.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
>> Zip files can, of course, be stored with uncompressed entries. On<br>
>> disk format does not need to match distribution format. Delta storage<br>
>> on the file system (or journal) makes most of what you seem to be<br>
>> claiming irrelevant. Perhaps you need to study the internal structure<br>
>> of ZIP more closely? (While you are at it, studying how rsync works<br>
>> will help you understand how compression and delta storage interact;<br>
>> in particular look at the --rsyncable option to gzip.)<br>
><br>
> I am specifically talking about delta storage. A naive tgz causes an<br>
> obnoxiously large delta. A tarfile can have tiny deltas. I am not sure where<br>
> zip and --rsyncable lie on this continuum, and whether they are good enough.<br>
> (--rsyncable is interesting, and I was not aware of it.) I do not even know<br>
> which of those two options is better. This is a question that should be<br>
> answered empirically, with some real bundles as examples.<br>
<br>
</div>AGAIN, PLEASE READ THE STUFF I ASK YOU TO READ BEFORE MAKING ME READ A RESPONSE!<br>
<br>
Thank you.</blockquote><div><br>Please, let's treat each other with respect. I did respond to you. It is a fact that both zip an gzip --rsyncable still have the potential to propagate a small change, even though both of them do place limits on how far this change can propagate. I acknowledged this in my response. <br>
<br>You may think it ridiculous that I want empirical data on the relative sizes. You may be right that zip format can be assumed to be good enough, given that the most dysfunctional case for zip deltas - a single large subfile subject to frequent, small, sequentially-early changes - will be uncommon in a bundle. But please do not yell at me and tell me to "read the stuff" when you did not give me a link, I did do a google, and my response reflected that. I have a similar impression that you are reading my responses superficially, yet I know misunderstandings happen between intelligent people.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
> Can, yes. However, when is it worth using an established format? I would<br>
> argue that when it would be excruciating to use existing tools for that<br>
> format by hand; when most such tools are written in a language that does not<br>
> even run on your target platform; and when your special needs are large<br>
> enough and against the grain of the format enough that using that format<br>
> makes the job harder, both in terms of initial programming effort and<br>
> upkeep; then the gain is not worth it.<br>
<br>
</div><a href="http://www.google.com/search?q=fastjar" target="_blank">http://www.google.com/search?q=fastjar</a></blockquote><div><br>A tool which does nothing in terms of signatures.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<a href="http://www.google.com/search?q=fastjar" target="_blank"></a><br>
<br>
It is worth using existing formats even if you have to rewrite all<br>
your tools from scratch, because the format has been used and tested<br>
and understood by more people than just you. In fact, formats with<br>
multiple implementations are *preferred*, because that shows that they<br>
are well understood.</blockquote><div><br>You are right, if those formats solve the problem you need to solve. If, even after you rewrite the tools from scratch, they get you no closer to a solution than you started out, it is at least debatable if that was worth it. <br>
<br>Consider:<br>Jar defines only two signature formats (md5-rsa and dsa), both of which are ready for deprecation. So I have to do that myself.<br><br>Jar gives no inherent way to decide what content does or does not need a signature. So I have to do that myself. (And when I do, I must, for compliance, uselessly duplicate the list of files which need a signature as many times as I have signatures on those files.)<br>
<br>Jar gives me, as far as I can tell, no useful tools for building valid bundles (using fastjar takes about the same number of lines of python as doing it natively from python, though it is probably faster). So I might as well do that myself.<br>
<br>Jar does not allow metadata to be included with a signature. So I have to keep track of metadata in a separate file - not too hard, as you say. Worse, I have to write the glucose signing service such that it puts this minor but confusing job in the lap of any other activity which wants to use signatures. So here, I'm worse off than I was without it.<br>
<br>Even when I do all that, Jar does not give me any help in defining what chain of signatures is valid. Again, do it myself.<br><br>What does it give me? Some directory, file, and attribute names; some definitions of whitespace, picky line length limits, and some more elements of an underdefined manifest specification. That's great; I would be happy to use the naming and other conventions from the jar spec, insofar as they don't get in my way. But since any checker which validates jar spec compliance will get me about 10% of the way to proving that a given bundle is valid by my definition, the fact is in effect I am writing my own spec anyway. I would say that is more helpful to make that fact clear by deviating from the jar spec when it is convenient.</div>
</div><br>