I'm working on implementing vCard editor for xmpp. In the process I found
out that the
might need to be modified:
- Currently the addDetail(), replaceDetail() and removeDetail() methods
are used to directly interact with the ServerStoredDetails which are on the
server. This means that if the user wants to modify multiple details about
himself, we have to call multiple times these methods and therefore access
the server stored details multiple times (in the jabber case this means
that for every user's ServerStoredDetail we have to load the vCard, parse
it, modify it and then store it back on the server).
This would be extremely slow and unpractical.
I'm suggesting that we change the addDetail/replaceDetail/removeDetail
methods in a way that they only cache account information. Then we can add
a save() method to the interface that will interact with the server.
We can just make sure that we do add/replace/remove once the save button is
clicked, so we do not modify anything before save, this way if user cancels
the account modifications no change will be made. If we do it this way,
then in those three methods only the save part (the store of the vcard in
terms of xmpp provider) need to be moved in the new method. Not so much
modifications, I think.
Of course if we do that we will have to also modify the currently existing
implementations of the OperationSetServerStoredAccountInfo and rewrite
their unit tests which will take some time.
This save method was missing while making icq provider, and so its tests
were very slow, because on every change 6 or 7 packets were sent and we
wait for confirmation after the last one, which is also slow at
server-side. Anyway I don't think we need to worry about those icq tests,
because we had a lot of failed tests from time to time and as icq is no
more supported and no contribution to it or the library we use for it was
made for several years, that's why we also stopped those tests and they are
currently not running. Although the change there will be just to add a save
method after every change, just to be there if someone starts looking at
them some day
On Fri, Sep 27, 2013 at 2:16 PM, Marin Dzhigarov <email@example.com> wrote:
However, I can't think of any other options.
Please, feel free to suggest different approaches if you see any.
dev mailing list
Unsubscribe instructions and other list options: