Deprecate update stream?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Deprecate update stream?

Frank Shearar-3
Utilities' "fetching updates" category seems obsolete - that's all the
bits to work with an update stream, isn't it?

If we want to continue with infrastructure for an update stream, why
don't we put all this stuff together in its own package? Especially,
can we pull the state out of Utilities? UpdateDownloader and
UpdateUrlLists belong together in a separate object.

It's not just Utilities though - I've seen a whole bunch of methods
all over the place (he says not bothering to go find all those places)
that look like they deal with update streams. These could also go into
this new package.

It ought to be the work of a few hours, for someone keen to improve
the state of affairs!

frank

Reply | Threaded
Open this post in threaded view
|

Re: Deprecate update stream?

Nicolas Cellier
What is the last time this code were used? 3.8 image?
The clean way is to isolate a package then remove it (if we think that code has an interest and could be revived).
Otherwise, the fast way is to just remove...


2013/11/24 Frank Shearar <[hidden email]>
Utilities' "fetching updates" category seems obsolete - that's all the
bits to work with an update stream, isn't it?

If we want to continue with infrastructure for an update stream, why
don't we put all this stuff together in its own package? Especially,
can we pull the state out of Utilities? UpdateDownloader and
UpdateUrlLists belong together in a separate object.

It's not just Utilities though - I've seen a whole bunch of methods
all over the place (he says not bothering to go find all those places)
that look like they deal with update streams. These could also go into
this new package.

It ought to be the work of a few hours, for someone keen to improve
the state of affairs!

frank




Reply | Threaded
Open this post in threaded view
|

Re: Deprecate update stream?

David T. Lewis
On Sun, Nov 24, 2013 at 10:11:56PM +0100, Nicolas Cellier wrote:
> What is the last time this code were used? 3.8 image?
> The clean way is to isolate a package then remove it (if we think that code
> has an interest and could be revived).
> Otherwise, the fast way is to just remove...
>

In this case I think there is a very good chance that someone will want
to use this in the future, because it provides a very lightweight and
human-readable means of replaying an update stream, regardless of whether
that update stream was originally implemented using Monticello or some
other mechanism.

I like Frank's idea. Turning the old update stream mechanism into a
reloadable package would reduce the clutter of Utilities, and it would
hopefully preserve the update stream mechanism in a manner that would
make it easier to understand and maintain.

Dave

>
> 2013/11/24 Frank Shearar <[hidden email]>
>
> > Utilities' "fetching updates" category seems obsolete - that's all the
> > bits to work with an update stream, isn't it?
> >
> > If we want to continue with infrastructure for an update stream, why
> > don't we put all this stuff together in its own package? Especially,
> > can we pull the state out of Utilities? UpdateDownloader and
> > UpdateUrlLists belong together in a separate object.
> >
> > It's not just Utilities though - I've seen a whole bunch of methods
> > all over the place (he says not bothering to go find all those places)
> > that look like they deal with update streams. These could also go into
> > this new package.
> >
> > It ought to be the work of a few hours, for someone keen to improve
> > the state of affairs!
> >
> > frank
> >
> >

>


Reply | Threaded
Open this post in threaded view
|

Re: Deprecate update stream?

Nicolas Cellier
OK, go for the clean way if it is usefull, but then we must also publish the pre-trunk version of updateFromServer in this package.


2013/11/25 David T. Lewis <[hidden email]>
On Sun, Nov 24, 2013 at 10:11:56PM +0100, Nicolas Cellier wrote:
> What is the last time this code were used? 3.8 image?
> The clean way is to isolate a package then remove it (if we think that code
> has an interest and could be revived).
> Otherwise, the fast way is to just remove...
>

In this case I think there is a very good chance that someone will want
to use this in the future, because it provides a very lightweight and
human-readable means of replaying an update stream, regardless of whether
that update stream was originally implemented using Monticello or some
other mechanism.

I like Frank's idea. Turning the old update stream mechanism into a
reloadable package would reduce the clutter of Utilities, and it would
hopefully preserve the update stream mechanism in a manner that would
make it easier to understand and maintain.

Dave

>
> 2013/11/24 Frank Shearar <[hidden email]>
>
> > Utilities' "fetching updates" category seems obsolete - that's all the
> > bits to work with an update stream, isn't it?
> >
> > If we want to continue with infrastructure for an update stream, why
> > don't we put all this stuff together in its own package? Especially,
> > can we pull the state out of Utilities? UpdateDownloader and
> > UpdateUrlLists belong together in a separate object.
> >
> > It's not just Utilities though - I've seen a whole bunch of methods
> > all over the place (he says not bothering to go find all those places)
> > that look like they deal with update streams. These could also go into
> > this new package.
> >
> > It ought to be the work of a few hours, for someone keen to improve
> > the state of affairs!
> >
> > frank
> >
> >

>