[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] p2 repository optimization

> A couple of follow-up questions
> 1. If this support will not be in p2 release 1.0 ( which I believe
> is equivalent to eclipse 3.4 ), which eclipse release is it planned
> for and ( what is that target complete date for the specified
> eclipse release?)
      This may get addressed in the 3.5 timeframe. However it will likely
depend on the community involvement.



> 2. One of the reasons we are interested in this repository
> optimization is that for maintenace or point releases we would like
> to provide a "smaller" package. i.e. only include these optimized
> jar files with changes ( whether we would use the delta or full
> optimized jars - not sure yet ).
      If you are only looking for jars, then I would recommend you to look
at the "Jar delta optimizer" which
is less CPU and memory intensive. (
http://wiki.eclipse.org/Equinox_p2_Repository_Optimization#Class_Delta_Optimization)


> 3. So I image the tools will at some point proivde an ide interface
> to create a repository" ( similar to creating an update site today )?
      Our approach for 3.4 is to keep on using the update site editor as
input format. The build then will then produce the required files for p2.
      Longer term, we may revamp the editor and provide more advanced repo
tools, but here again it will depend on priority and community involvement.


> 4. It was mentioned in the reply below that "delta creation and
> recreation is time and space intensive, and the client should only
> download a delta in certain circumstances.." So should I expect that
> even tho I have a smaller "optimized" repository that the update of
> the jars will actually take longer than just updating full versions
> of the jars?
      I don't numbers, however this will definitely happen depending on
what your bandwidth to the server is. For example, when we turned on
pack200 support (which requires a non trivial processing on the client),
the installation of the SDK from a LAN slowed down because of the
computation involved to unpack the jar on the client. However from home,
things went much faster.


>
> thanks, Janet
>
> Janet Dmitrovich
> WPLC Expeditor Software Development
> jdmitrov@xxxxxxxxxx
> 512-838-4912 T/L:678-4912 FAX:512-838-3703
> 11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372)
>
>
>
> [image removed] Stefan Liebig ---02/13/2008 01:55:35 PM---There is
> already some work done in p2 but it will probably not get into p2
> version 1.0. I will explain the reasons for that lat

>
> Stefan Liebig <Stefan.Liebig@xxxxxxxxxxxx>
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 02/13/2008 01:54 PM
>
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
> [image removed]
> To
>
> [image removed]
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
> [image removed]
> cc
>
> [image removed]
>
> [image removed]
> Subject
>
> [image removed]
> Re: [equinox-dev] p2 repository optimization
>
> [image removed]
>
> [image removed]
>
>
> There is already some work done in p2 but it will probably not get
> into p2 version 1.0. I will explain the reasons for that later.
> Full Delta optimization works similar as the Jar Delta Optimization
> except that the full delta algorithm used is a binary delta
> algorithm working on the byte level. The binary delta algorithm we
> use is an extension of jbdiff (http://freshmeat.net/projects/jbdiff/) .
> The optimization creates deltas between artifacts of different
> versions. For compressed artifacts (jar/zip) the artifacts will
> first be decompressed and than the delta generation is performed on
> the uncompressed artifacts. The client can now choose a delta for
> download if it has the required ´base´ artifact version ´locally´
> available. With this base version and the delta the ´targeted´
> artifact version can be recreated.
> This delta creation and recreation is time and space intensive and
> the client should only download a delta in certain circumstances,
> e.g. low bandwidth connection, expansive connection, good processing
> speed and enough memory of client machine. The current p2
> DownloadManager will probably not be able to reach a decision on
> what the best download strategy could be.
>
> Stefan
>
> Janet Dmitrovich wrote:
> On the wiki - the description for "Full Delta Optimization" is "in
> progress..."
> Is there any other information available on this?
>
> http://wiki.eclipse.org/Equinox_p2_Repository_Optimization
>
> Janet Dmitrovich
> WPLC Expeditor Software Development
> jdmitrov@xxxxxxxxxx
> 512-838-4912 T/L:678-4912 FAX:512-838-3703
> 11501 Burnet Road, Austin TX 78758 (Internal ZIP: 9372)
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>  _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev[attachment
> "pic27119.gif" deleted by Pascal Rapicault/Ottawa/IBM]
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev