Layout Archiving in Haiku

My plan for layout archiving focuses mainly on a few related objects, which manage the [de]archiving process:

I will name these classes as I go along, but theses names are not final at all. Also, although this greatly resembles c++ code, its only purpose is to illustrate my ideas, it would make a compiler grumpy.

//important classes
class LayoutArchiveManager;
class LayoutArchiver;
class LayoutDeArchiver;
class BPrivate::LayoutArchiverPrivate;
class Bprivate::LayoutDeArchiverPrivate;
class SomeKindOfVector;


class LayoutArchiveManager
{
 public:

   //returns the new sessionToken
   int NewArchivingSession(BMessage* topLevelArchive);
   LayoutArchiver GetArchiver(int sessionToken);//or maybe (Bmessage* archive)

  //also returns a sessionToken, but it is fished out from topLevelArchive
   int NewDeArchivingSession(BMessage* topLevelArchive);
   LayoutDeArchiver GetDeArchiver(int sessiontoken );//or maybe (Bmessage* archive)
   //same idea but for de-archiving

  ...
  private:
  friend class LayoutArchiver;
  friend class LayoutDeArchiver
   void DereferenceArchiver(int token);
   void DereferenceDeArchiver(int token);
};
extern LayoutArchiveManager *gLayoutArchiveManager

class LayoutArchiver
{
  public:
   int GetToken(BView *subject);
   int GetToken(BLayoutItem *subject);
   //creates a token that can be used later in dearchiving

  /* these methods assign a token to the object, and add some info to the archive. They should be called before GetToken() is called, e.g. to allow children view to get the token of  their parent*/
   void RegisterArchive(BMessage* archive, Bview* );
   void RegisterArchive(BMessage* archive, BlayoutItem* );

  ~LayoutArchiver() { gLayoutArchiveManager->DereferenceArchiver(fArchiver->Token()); }
 private:
   friend class LayoutArchiveManager;
    LayoutArchiver(LayoutArchiverPrivate* archiver);
 private:
	LayoutArchiverPrivate* fArchiverPrivate;
};


class LayoutArchiverPrivate
{
  private:
     friend class LayoutArchiveManager;
     LayoutArchiverPrivate();
     int references;
   private:
     friend class LayoutArchiver;
     int GetToken(BView* subject);
     int GetToken(BLayoutItem* subject);
     int Token();
  private:
   someKindOfVector<BView*>* fViews;
   someKindOfVector<BLayoutItem*>* fLayoutItems;
   Bmessage* fTopArchive;
   int fSessionToken;
};

So, that is about what will be used in archiving. As you can see, there is a global object that oversees any and all archiving. The LayoutArchivers that it passes out allow us to implement reference counting so that as they go out of scope, gLayoutArchiveManager will decrement LayoutArchiverPrivate::references for the appropriate LayoutArchiverPrivate. When a Bview wishes to archive it's children, it must simply add a field into the Bmessage that their child will be archiving in which holds the token for this archiving session. This token will be used later to ask gLayoutArchiveManager for a LayoutDeArchiver. As an object (either Bview or BlayoutItem) is archiving itself, it notes which tokens represent the other objects it references in its archive.

So, that should give anyone reading this the gist of the archiving process, but that is only half the story isn't it? So, on to dearchiving!

The de-archiving process is fairly simillar, but is also a bit more complex. We now have, instead of RegisterArchive, ClaimToken, which works in a very similar fashion.  It is important to note that between an object calling either of these methods on their Layout[De]Archiver and finishing their constructer, some methods should not be called. What I might do is make two more classes which act as proxies of Bview and BlayoutItem to enforce this. Instead of GetView() returning a Bview*, it would return one of these proxies for example. Such a class might also replace Bview* Parent() with int Parent() (return the parent's token), to make life a little easier. The type of methods restricted would be things like Parent(), ChildAt() etc. Anyway, the most important method of the dearchiving process would be LayoutDeArchiverPrivate::Get...(), in the event an object has not yet been constructed, this method would recursively search through fArchive, find the appropriate Bmessage archive, have the object de-archive itself and then return the newly created object. Alternatively, the different messages could be unpacked into SomeKindOfVector and accessed when the LayoutDeArchiverPrivate is constructed, which would be faster.

class LayoutDeArchiver
{
  public:
  //if the appropriate Object has already been built, a pointer is returned, otherwise, it is built
   Bview* GetView(int token);
   BLayoutItem* GetLayoutItem(int token);

  /*during an object's construction, and before it calls Get...(), it will call ClaimToken(), although the  object will not yet be fully constructed, it will be constructed enough :D*/
   void ClaimToken(int token, Bview* subject);
   void ClaimToken(int token, BlayoutItem* subject);

  ~LayoutDeArchiver()
      {gLayoutArchiveManager->DereferenceDeArchiver(fDeArchiver->Token()); };

  private:
   friend class LayoutArchiveManager;
   LayoutDeArchiver(LayoutDeArchiverPrivate* privateDearchiver);

  private:
    LayoutDeArchiverPrivate* fDeArchiver;
 };


class LayoutDeArchiverPrivate{
 private:
   friend class LayoutArchiverManager;
   LayoutDeArchiverPrivate(BMessage* archive);
   int references;

 private:
   friend class LayoutArchiver;
      Bview* GetView(int token);
      BLayoutItem* GetLayoutItem(int token);
      void ClaimToken(int token, Bview* subject);
      void ClaimToken(int token, BlayoutItem* subject);

 private:
   someKindOfVector<BView*>* fViews;
   someKindOfVector<BLayoutItem*>* fLayoutItems;
   Bmessage* fTopArchive;
   int fSessionToken;
};

A note on thread safety: I would like to make this process thread safe, although large chunks would still have to happen serially, some actons could probably be parallelized.

Alright, I think that covers it, If I've missed anything, please e-mail me and I will update this. Hopefully this answers any questions on the subject!

One more note:  as I said earlier, the names of classes, methods etc. May change, as may the actual method signatures. However, the general idea behind these classes should remain relatively static. For example, I will probably create a base class for LayoutArchiverPrivate and LayoutDeArchiverPrivate to share, as they have alot in common.

Thanks for reading!
Alex