New file structure

[Anders Olofsson]

I've just pushed several commits (to master) that will make a large
migration to ~/.licq the next time Licq runs.
It is highly recommended to backup your .licq directory before running
in case anything goes wrong. I've tested what I can think of but
everyone makes mistakes.

The migration is triggered if Version in licq.conf is lower than "1080".
So, anyone who is running Licq from git master must edit licq.conf and
change Version to something lower before starting Licq ("1079" works
fine) or the migration will be skipped and there will be many problems.

If anyone experiences problems due to this, please let me know so we can
try and fix it before it becomes an official version.
For better troubleshooting, run "licq -d15" from a shell to get log
output and remember to clear out your password(s) if you need to send or
paste anything.

Also, the ICQ protocol is now a plugin that needs to be built and
installed separately.


The purpose of this migration is to make the file structure in .licq
compatible with multiple owners per protocol by adding subdirectories
per owner to hold data, pictures and history files.
I also took the opportunity to move several config file migrations to
the upgrade function to clean up after some other changes done over the
last years.

Note that multiple owners per protocol still isn't enabled, but (at
least in theory) the daemon and GUI should be able to handle it if only
the safety checks are removed. The ICQ and MSN protocols will require
additional work, but I believe the Jabber protocol could easily be
updated by replacing myClient with a map<UserId,Client> in the Plugin class.
However, since I don't use Jabber myself I won't be able to verify this
and therefore I probably won't dare to just enable it at this time, but
I could make a good guess in a separate branch if anyone is interested
in getting it to work.

/Anders

[Erik Johansson]

On Tue, Jan 1, 2013 at 3:34 PM, Anders Olofsson <fl...@licq.org> wrote:
> If anyone experiences problems due to this, please let me know so we can try
> and fix it before it becomes an official version.
> For better troubleshooting, run "licq -d15" from a shell to get log output
> and remember to clear out your password(s) if you need to send or paste
> anything.

Great work!

I tried to latest version and noticed that what looks like a left-over
in licq.conf under [groups]. For each group I have
GroupX.ServerId.LicqUIN=Y and GroupX.ServerId.ICQ_UIN=Y. I'm guessing
that only the second one should be there?

> Also, the ICQ protocol is now a plugin that needs to be built and installed
> separately.

Finally! Again, great work!

> The purpose of this migration is to make the file structure in .licq
> compatible with multiple owners per protocol by adding subdirectories per
> owner to hold data, pictures and history files.

Nice.

> Note that multiple owners per protocol still isn't enabled, but (at least in
> theory) the daemon and GUI should be able to handle it if only the safety
> checks are removed. The ICQ and MSN protocols will require additional work,
> but I believe the Jabber protocol could easily be updated by replacing
> myClient with a map<UserId,Client> in the Plugin class.
> However, since I don't use Jabber myself I won't be able to verify this and
> therefore I probably won't dare to just enable it at this time, but I could
> make a good guess in a separate branch if anyone is interested in getting it
> to work.

Instead of making each plugin handle multiple owners, is it possible
to create multiple instances of the plugin's main class instead and
bind each owner to a separate instance?

// Erik

--
Erik Johansson
Home Page: http://ejohansson.se/
PGP Key: http://ejohansson.se/erik.asc

[Anders Olofsson]

> I tried to latest version and noticed that what looks like a left-over
> in licq.conf under [groups]. For each group I have
> GroupX.ServerId.LicqUIN=Y and GroupX.ServerId.ICQ_UIN=Y. I'm guessing
> that only the second one should be there?

Yes, one of the side effects of the switch from LICQ_PPID to ICQ_PPID
that I missed.
I've added code to patch it as part of the migration now.
Thanks for catching it.

>> Note that multiple owners per protocol still isn't enabled, but (at least in
>> theory) the daemon and GUI should be able to handle it if only the safety
>> checks are removed. The ICQ and MSN protocols will require additional work,
>> but I believe the Jabber protocol could easily be updated by replacing
>> myClient with a map<UserId,Client> in the Plugin class.
>> However, since I don't use Jabber myself I won't be able to verify this and
>> therefore I probably won't dare to just enable it at this time, but I could
>> make a good guess in a separate branch if anyone is interested in getting it
>> to work.
>
> Instead of making each plugin handle multiple owners, is it possible
> to create multiple instances of the plugin's main class instead and
> bind each owner to a separate instance?

Hmmm, I hadn't even thought about doing it that way ...

I guess the biggest difference in the end would just be how many threads
the plugins are running.
It would require changing the PluginManager to keep track of both
libraries and instances separately.
It opens the question of what actually needs to exist for a protocol
that is loaded but has no owner configured. I'm guessing there should
still be some small singleton per protocol to hold static data like the
protocol name, capability flags, etc...

I think just fixing the Jabber main loop would be the quickest way to
just get something running, but I'm not sure which way is the better
long term solution. This needs some more thought ...

However, both MSN and ICQ still have globals that makes it impossible
for them to have multiple instances, regardless of where it is managed.
So for now, Jabber is the only available candidate.

/Anders

[Erik Johansson]

On Tue, Jan 1, 2013 at 10:03 PM, Anders Olofsson <fl...@licq.org> wrote:
>> Instead of making each plugin handle multiple owners, is it possible
>> to create multiple instances of the plugin's main class instead and
>> bind each owner to a separate instance?
>

> I guess the biggest difference in the end would just be how many threads the
> plugins are running.
> It would require changing the PluginManager to keep track of both libraries
> and instances separately.

I think it would be good if protocols don't have to handle multiple
owners explicitly. It will probably make them easier to grasp. I've
started looking into how this could be done.

> It opens the question of what actually needs to exist for a protocol that is
> loaded but has no owner configured. I'm guessing there should still be some
> small singleton per protocol to hold static data like the protocol name,
> capability flags, etc...

This can be a later improvement. Previously I have thought about
making each plugin have a xml-file (or other format) that describes
the plugin. This way you could list some info about each plugin
without having to load them.

[Anders Olofsson]

On 2013-01-02 21:58, Erik Johansson wrote:
> On Tue, Jan 1, 2013 at 10:03 PM, Anders Olofsson<fl...@licq.org> wrote:
>>> Instead of making each plugin handle multiple owners, is it possible
>>> to create multiple instances of the plugin's main class instead and
>>> bind each owner to a separate instance?
>>
>> I guess the biggest difference in the end would just be how many threads the
>> plugins are running.
>> It would require changing the PluginManager to keep track of both libraries
>> and instances separately.
>
> I think it would be good if protocols don't have to handle multiple
> owners explicitly. It will probably make them easier to grasp. I've
> started looking into how this could be done.

I would like to bring down the number of running threads, especially in
the ICQ protocol, but I guess one per owner isn't that bad.

But what would happen if you have a different type of protocol?
Example 1: A skype interface that talks to the Skype application via
D-Bus don't know which account the Skype client has configured until
after it's connected. Here it would make more sense to let the protocol
fetch the account id from the Skype client and than add it itself to
Licq. (A Skype plugin also adds some other strange things, like how to
differ between not connected to the Skype client, and connected but the
Skype client is offline.)
Example 2: A weather plugin (I know it exists for other IM clients) or
similar status information may not have any type of real account. If it
starts when loaded, it can add its own hardcoded dummy account rather
than forcing to user to do it.

I'm also thinking about flexibility for how the protocol is threaded.
If we only start one thread (as today) it would be possible for the
protocol main class to spawn additional threads for each owner if it
wants to. But if we start one thread per owner and the protocol only
wants/needs one global thread, it could get a bit tricky.


Anyway, which ever way we do this I'm assuming we just can't enable it
globally for all protocols (due to globals in some protocol's code) so
I've added a new capability flag for protocol plugins to control if
multiple owners are supported, and I've updated everything I could
remember in the daemon and GUI to check for that flag instead of just
hardcoding one owner per protocol.

>> It opens the question of what actually needs to exist for a protocol that is
>> loaded but has no owner configured. I'm guessing there should still be some
>> small singleton per protocol to hold static data like the protocol name,
>> capability flags, etc...
>
> This can be a later improvement. Previously I have thought about
> making each plugin have a xml-file (or other format) that describes
> the plugin. This way you could list some info about each plugin
> without having to load them.

A separate file is an option, and it would be nice to have the
information available before the library is loaded, but having it inside
the library is a guarantee that the information is in sync with the
library code.
However, if you do want to make a file, please keep away from xml. Xml
only makes it harder to parse the file and for this case I can't see
that we benefit from any of the flexibility in XML. A simpler format
(like the INI-files we use for everything else) will be easier to parse
both for Licq and humans, and as long as the first parameter is a
version (Licq version or file format version) it doesn't matter if the
format for the rest of the file changes between versions.

/Anders

[Erik Johansson]

Hi,

On Wed, Jan 2, 2013 at 9:58 PM, Erik Johansson <er...@ejohansson.se> wrote:
> I think it would be good if protocols don't have to handle multiple
> owners explicitly. It will probably make them easier to grasp. I've
> started looking into how this could be done.

I have something working now and have been able to add multiple jabber
accounts and chat with myself :)

The code needs a bit of cleanup before it can be published though.