Migration Strategy

I'm planning to perform a step-by-step migration. This means I'll not just rip ThunarVFS out (like I usually would end up doing) and then try to fill the holes. Instead, I'll migrate from ThunarVFS to GIO in several steps, always trying to keep Thunar functioning while I'm at it.

There are several ways to do this. Their ups and downs have to be evaluated before I can start to work.

Bottom-Up

The general idea is not to touch the APIs at all in the beginning. Don't change function signatures. First replace all function bodies which use ThunarVFS with equivalent implementations based on GIO. Later go through all classes using GIO code and remove ThunarVFS references.

Advantages

  • Easy to keep Thunar functioning at the beginning
  • Progress can be seen very quickly

Disadvantages

  • Doesn't necessarily work well with the asynchronous APIs in GIO
  • Some classes/concepts in Thunar probably need a complete redesign

Top-Down

Mixture Of Both

Others?

 
preparation/strategy.txt · Last modified: 2009/03/19 13:01 by jannis
 
Except where otherwise noted, content on this wiki is licensed under the following license:CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki