Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] JEP 336: deprecate pack200



On Tue, Jun 26, 2018 at 10:53 AM, Lars Vogel <lars.vogel@xxxxxxxxxxx> wrote:
Hi Mickael,

AFAIK the webserver is typically the one which should do the
compression (using Gzip compression).

So maybe it is better to do this on the transport layer?

Is there any measurement about the compress ratio of httpservers gzip and pack200 and gzip+pack200 ? It would be nice to have some data so we would know what the real loss would be before deciding what the solution would be.
 

The fastest HTTP engine to my knowledge it OKHttp, which is the one
used in Android devices. http://square.github.io/okhttp/  OKHttp
supports transparent GZIP.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=477524 as an enhancement
request for ECF to support OKHttp.

Best regards, Lars

On Tue, Jun 26, 2018 at 9:31 AM, Mickael Istria <mistria@xxxxxxxxxx> wrote:
> Hi all,
>
> On the p2-dev mailing-list, a user/contributor has mentioned this JEP:
> http://openjdk.java.net/jeps/336 . It's about removing pack200 from JRE.
> The user message and a following discussion are available at
> https://dev.eclipse.org/mhonarc/lists/p2-dev/msg05770.html
>
> pack200 is heavily used by p2 to reduce download size/time.
> The big question is, if it's not standard any more, what are the possible
> choices and their pros/cons:
> * Plan1: p2 contributors switch p2 to an alternative implentation of pack200
>   ** Pros
>      *** No functional change
>      *** Still smaller download size/time
>   ** Cons
>      *** Need to find a good pack200 un/compression engine (seems like a
> hard task), or to help one if getting good enough to be a substitute
> (slightly harder), or to author a good one (extremely harder); and help
> maintaining them on the long run (hard)
>      *** Adapt p2 to use a newer compression engine
>      *** overall, the 2 ones fail in the category "it's a lot of work".
> * Plan2: drop pack200 from p2 on future Java
>   ** Pros
>     *** relatively simple, p2 most likely has the switches to ignore pack200
> already, so we can just configure those according to whether JRE ships
> pack200
>     *** sustainable and easier maintenance on the long run
>   ** Cons
>     *** Bigger downloads when updating, more load on download.eclipse.org
>
> Plan 2 has the big advantage of requiring less effort. The big question is
> would download.eclipse.org scale enough to serve non-packed artifacts?
> And maybe other questions to discuss?
>
> Note that for the architecture council, I think the right grain of
> discussion is mostly to evaluate whether dropping pack200 support would be a
> major issue or not.
> For technical implementation details (p2 dynamically chosing pack200 or not
> according to JRE, considering other compression formats...), then the p2
> bugtracker and mailing-lists are more appropriate.
>
> Cheers,
>
> --
> Mickael Istria
> Eclipse IDE developer, for Red Hat Developers
>
> _______________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
> IMPORTANT: Membership in this list is generated by processes internal to the
> Eclipse Foundation.  To be permanently removed from this list, you must
> contact emo@xxxxxxxxxxx to request removal.



--
Eclipse Platform project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.



--
Alexander Kurtakov
Red Hat Eclipse Team

Back to the top