In line ...
I just noticed that we generate the jars for the Jitsi bundles without
compression. I see how that makes sense in Jitsi where they are not
stored in the repository, and are distributed in a package which is
itself compressed. However, now that we're using them in other projects
(videobridge, jigasi, jicofo) where they are stored as blobs I think it
would be good to compress them (libjitsi.jar is now 6.6MB, while 3.4MB
What do you think? Am I missing something here (I assume the load time
different for the jvm is negligible), or should I open an issue about this?
a) As Git compresses binaries and only stores deltas, it shouldn't make a difference if we compress the jars before committing or not. It's possibly even backfiring if we'd do so because the delta between two compressed binaries is probably bigger than between two uncompressed ones.
Also, if libraries are uncompressed, then it might be way easier for git
to store compress, given that the content of the file reflects the
actual changes in the code. I mean, if you use compression, then given
by how the dictionary is composed, contents might change significantly.
While, on the other hand, an uncompressed library will basically have
the same content, only maybe slightly offsetted.
b) We should make more libraries and reference the projects instead of copying blobs around projects. For a start, this could be done with Git submodules  and importing Jitsi's Ant script into Videobridge, Jicofo, etc. A proper modularization into small, distinct libraries with whatever build system could come later.
Have you worked with submodules / subtrees before? Whenever I read into
the subject I get confused by which is better in the "general" case and
how one should use them. I don't mind using them, but I don't have a
clear image of how we should. (I've also read on occasion hints on how
"the other one" is better, but without a real clarification.)
On 13-04-15 09:22, Ingo Bauersachs wrote:
dev mailing list
Unsubscribe instructions and other list options: