[Fwd: AbiCollab refactoring]

This is not really useful for people not knowing the current abicollab
architecture, but I think the part below

  "* The "My Documents" dialog we have now for c.a.c. should rea[...]"

is. Feel free to comment.

Marc

attached mail follows:

Hi Martin!

I've done a LOT of thinking about all the problems we have in AbiCollab
at the moment (although they might not be obvious to see if you are not
too familiar with all the connection handling). Some of the problems I
already described on IRC. I present some new ones below, and the
solution I want to try to implement:

* At the moment, AbiCollab's are created/managed by the
AbiCollab_FactoryContainer. For a start, I'll rename that to
AbiCollabSessionManager.

* What we call "AbiCollab" now, should really be called
AbiCollabSession. They will be, just like now, be managed by the
AbiCollabSessionManager.

* As discussed on irc, every session with have it's own unique ID (a
session id). This is needed because while the docUUID gives us enough
information to determine which AbiCollabSession should handle a
particular ChangeRecord, it doesn't tell us if said record is really
ancient (read: from a different editting session) and that we could
simply drop it. Such a situation can easily occur, as most XMPP servers
cache incoming packets when the receiving end is not connected.

* At the moment, every AbiCollab has it's own ConnectionHandler(s). This
is really bad: a lot of the XMPP servers out there only allow 1
connection per user per IP for example. To fix this problem,
ConnectionHandlers will be made 'global' and shared by the
AbiCollabSessions. The ConnectionHandlers will be managed by the
AbiCollabSessionManager. All message handling will be removed from the
AbiCollabSessions themselves, and be done by the
AbiCollabSessionManager.

* Observe this problem we have now:
   - User A shares 2 documents by manually connecting (twice!) to an
XMPP server
   - User B connects to user A
   - User B receives a random(!!) document, depending on to which
connection of user A the XMPP server sends the message to (I've seen
this happen, which means it is really broken now).

The global ConnectionHandlers are only half of the solution to this
problem. To fix the other half, user B needs to be presented with a list
of the documents user A has shared, so he can select which one to open.
Thus, he should be able to request a list of shared documents from a
buddy.

IMPORTANT: compare this to the GetDocumentsRequest packet of c.a.c,
which does really just that!

* The previous remark shows the need for every ConnectionHandler to have
a ::GetDocumentsRequest(...) function. It should be passed a "buddy" to
retrieve the document list from a particular buddy.

* The "My Documents" dialog we have now for c.a.c. should really be used
all the time, now that we get lists of documents from all our buddies.

To come up with a good dialog, first note that currently our menu items
are really weird: the manual connect and disconnect options seem to the
user to work for the current document, but they are in fact global.
Also, they don't allow you to tell which documents you have open are
shared or not. At the moment, all documents are shared (and randomly
sent to a connecting user, see above!).

Adapting the current c.a.c a dialog to something like the following will
work better I think (for all documents!):

-----------------------------------------------------------
 Documents Sharing
-----------------------------------------------------------
 Local Documents | Manage Connections
  |- DocumentA [ ] Shared | Add a Friend
  |- DocumentB [X] Shared |
                                       |
 My Account |
  |- Home |
     |- Foobar [ ] Join |
  |- Test folder |
     |- Foobar2 [X] Join |
     |- Foobar3 [ ] Join |
     |- Foobar4 [ ] Join |
                                       |
 John's documents |
  |- DocumentC [ ] Join |
  |- DocumentD [ ] Join |
                                       |
 My Assignment Group |
  |- DocumentC [X] Join |
  |- DocumentD [ ] Join |
-----------------------------------------------------------

Also observe that this dialog can be used to list a lot of things at the
same time:

  * Local documents
  * Your documents from c.a.c
  * Documents from friends from c.a.c
  * Documents from groups from c.a.c
  * Documents from manually added friends
  * Documents from friends on your local network (found by avahi, see
below)
  * etc etc etc

It also easily allows you to select which documents you want to share,
and which ones your want to join. All with a single click.

There will also be no special c.a.c. menu item anymore. When you press
the "Manage Connections" button, you will be able to connect with
various methods:

  * AbiWord Collaboration Service (needs just a username/password)
  * Jabber server (all the stuff from the manual dialog we have now)
  * Avahi (when you enable this, it will automatically show all buddies
on the LAN in the dialog above (neat, huh!)
  * Start a server on an IP/Interface
  * Join a server on an IP
  * ... and more :)

This means that our "Collaboration Service" is just a special case of a
connection handler now (think of an "XMPPServiceConnectionHandler). This
will remove a LOT of the hackery we have going on now.

I understand that I/we will have to do some massive refactoring, but
this is waaaay nicer than the weird manual/c.a.c seperation we have now.
And I don't even know how we could possibly integrate Avahi in the
_current_ situation. However, avahi and other methods blend in naturally
in the above structure.

Feel free to kick me about the above. I know I'm not clear on a lot of
issues, so just ask about what you don't get/don't agree on. If you
agree on most stuff, I think the best thing to do is to let me start
with the refactoring as I have a lot of the details in my head.

We shouldn't have to drop a lot of the code we currently have, it just
needs reworking.

Bye!
  Marc
Received on Mon Sep 25 00:22:15 2006