Proposal: "backend" layer

[boyska]

Hi everyone! I'm pretty new (I just took part to the name "discussion") here, but I found the aMsn2 project exciting, so that I'd like to contribute. Unfortunately, I'm a total newbie on protocols&network, so I'll take part only when the project will be in a more advanced status.
Now, I read some documentation I found, and I really like the idea of "multiple frontends"... but, I think, it will be useful to have even custom backends.
Backend is what we use to store datas, get password and so on. For example, to look like a *native* kde apps, qt is good but not enough: you should be integrated with kde "wallet" (for who doesn't know, a centralized password manager), with nepomuk and so on. For gnome, the same ideas apply (it use a wallet, too, if I'm not wrong, maybe we should get some infos from gconf and so on), as for windows and mac.

I know this will require more work, but this is the same problem of the "multiple frontends" choice, whit the same benefits.

Maybe I'm too late to say this, but, well, it's just a proposal

[billiob]

Whenever someone code that, it'll be done

[boyska]

Whenever someone code that, it'll be done

wow I'll try to make a "draft", copying the approach you used for the frontends, so that you can give opinions and decide what a "backend" should consist of.

edit: reading the code, I noticed that the whole "profile" module should be considered as part of the backend.
So, now I have to think of all backend cases, what should and what shouldn't be in there. If you have suggestions, please tell me Coding it should be quite simple (I hope)

[H@t Trick]

I don't like this idea, this would break a common user experience in aMSN on all platforms, I like having the program behave the same way in linux and Windows, part of that is the profile. Modular front ends only really facilitate a visual theme like experience, and all front ends should work on every platform (EFL will eventually work on Windows it seems). Please keep the user experience the same across all platforms.

A program does not need to use the Mac keychain or the KDE wallet, unless it only runs on that platform.

[boyska]

I don't like this idea, this would break a common user experience in aMSN on all platforms, I like having the program behave the same way in linux and Windows, part of that is the profile.

The program WILL behave the same way. But for example, it could discover proxy settings through gconf (if you use gnome) or from windows register (on win); if we keep a "basic" backend, we can't be too much integrated with the environment we're running on.

Hope to have clarified, thanks for your answer

[H@t Trick]

I didn't know proxy settings were global on Linux, as they are program specific on Windows. Some programs hook into the IE proxy settings like Norton Live Update, but Norton lets you set them independently. So for someone who doesn't use IE and if on the odd chance IE's settings are messed up. I do tech support for an ISP (shhhhh!!!) and I've had customers be able to surf on Firefox (which we don't support ) but not IE because the proxy settings were wrong, so hooking into these settings is probably not a good idea on Windows, and a reliance on IE is never a good thing.

As long as the user experience is the same no matter what the platform then thats good, but is there an absolute need to fully integrate with the user's environment?

Yes this has clarified things for me. I was under the impression hooking in the user's DE would change the user experience even between different Linux DE's and from Mac to Windows, etc.

The common user experience of a cross-platform app should always be the same (or as similar as possible) in my opinion. Thats what aMSN has right now.

[boyska]

I didn't know proxy settings were global on Linux, as they are program specific on Windows. Some programs hook into the IE proxy settings like Norton Live Update, but Norton lets you set them independently. So for someone who doesn't use IE and if on the odd chance IE's settings are messed up. I do tech support for an ISP (shhhhh!!!) and I've had customers be able to surf on Firefox (which we don't support ) but not IE because the proxy settings were wrong, so hooking into these settings is probably not a good idea on Windows, and a reliance on IE is never a good thing.

Oh, I didn't know the IE-thing, anyway it was just the first example I thought. Well, I don't know on Windows (it's ages since I used it) but on Linux a Qt application behaves very differently than a KDE one, and the same is for gtk-gnome.
Appearance is the same, but the behaviour seems to be more "coherent" for a kde/gnome one.
As an example, kde users are used to see their IM contacts automatically in kde addressbook (and so in every PIM application that is kde-aware). I think that similar things happens for gnome, maybe for Mac

As long as the user experience is the same no matter what the platform then thats good, but is there an absolute need to fully integrate with the user's environment?

I don't know if that is needed. Probably I have to try to hack it to see if it's simple: if it's simple, then it's ok. If it will be a pain, then probably aMsn2 don't need it

Yes this has clarified things for me. I was under the impression hooking in the user's DE would change the user experience even between different Linux DE's and from Mac to Windows, etc.

no, this won't happen

Thank you again

[boyska]

Finally I had an idea, hope you'll like it.
You can see an example of that in http://pastebin.com/f5954f2e9

The idea is very simple: we have a Data object that the core will use whenever he needs some datas.
I added just the first thing that came in my mind, but of course it's very easy to add new ones.
The "standard" Data does what aMsn would have done anyway. BUT we can add some classes that will extend the Data class.
Thanks to a bit of magic, you could for example add the MSOutlookData backend (that will, for example, get detailed information for your contacts) or the KDEWallet (that will be useful when saving passwords)

Opinions?

[billiob]

It's not the way i thougt of it.
I thought more of base class that inherits a UserDict, and have some load, save metods .... and every backend would inherit this base class.
And very important, a method to export and import a config. That way, H@t_Trick will be pleased (i'm not kidding, it's very usefull)

However i like your idea and it could be great for desktop integration.

I'm not alone on the project and you'll have to wait for KKRT's approval.

[boyska]

It's not the way i thougt of it.
I thought more of base class that inherits a UserDict, and have some load, save metods .... and every backend would inherit this base class.

yes, I thought in that way too
But then I thought that there are many things we can get integrated, and not always choosing ONE of this is the right thing.
For example, you could be using KDE but, instead of his mailer, another one (say, thunderbird). With this system you can integrate with every app you need. Anyway, I did this just to be more "complete". Your idea is very simple, so it will be easy to code.
About the dictionary, doing data['proxy'] or data.get_proxy() is just a matter of tastes, but with the dictionary method we need to get all the datas on startup, while with the "function" way we could get it just when we need them (of course, it's possible to apply the on-demand beaviour even with dict-style syntax, using a bit of __getattr__ magic )

And very important, a method to export and import a config. That way, H@t_Trick will be pleased (i'm not kidding, it's very usefull)

This shouldn't be difficult: we just need to take all the data and save them somewhere (an INI-file should be enough, but it depends on the favourite format of aMSN. Do we prefer xml, ini or whatever?)

However i like your idea and it could be great for desktop integration.

Wow, I'm glad!

I'm not alone on the project and you'll have to wait for KKRT's approval.

I know, I was just gathering some opinions, and giving some example code.
Hope he'll like it

[kakaroto]

hi!
not much time to post, but just wanted to quickly say that I like the idea.. I was thinking about trying to abstract the 'ecore_config' thingy from the EFL for the configuration system, but didn't think it would be useful in the end.. but I didn't know about the KDE wallet, and didn't think about gconf...
I think this is a great idea... have a 'desktop integration' other than the front end... in other words :
1 - applications to launch (mailer, browser, media player, etc..)
2 - configuration managers (ecore_config, windows registry, gconf, kde wallet...)
3 - platform/DE specific settings/behavior/etc...  

I think this will be an integral part of our original idea, because since the front ends will be stupid and the core will tell them everything they should be doing, then the core might also need to know from the DE what to tell the front ends... example : if your kde/gnome settings is "hide menus from applications" (if such option exists), it could have it by default set to hide the menus...
anyways, got to go.. great idea! and keep it up.

p.s.: I like the PoC.. the decorator idea is nice!

[H@t Trick]

Thanks to a bit of magic, you could for example add the MSOutlookData backend (that will, for example, get detailed information for your contacts) or the KDEWallet (that will be useful when saving passwords)

MSOutlookData? Forgive me for being a bit of a noob on this but that sounds like relying on a MS API (is that the right term in this case?), specifically for Outlook, which many users on Windows may not have installed or used. What if you use SeaMonkey or Thunderbird, or Eudora, or something other than Outlook (maybe it works with Outlook Express and the Windows Address Book, I don't know)? Just because I choose to use Windows XP (yes it is my honest personal choice as I have not found a Linux Distro I like for every day use yet and can not stand the look and feel and design of Mac OS X) does not mean I like to use Microsoft products, hence my continued use of aMSN and Mozilla products. I continually find myself seeking out freeware applications when I need a new program, and I will take an FOSS app over a free closed source app if both are equal in my mind. So relying on OS (Windows) APIs/tools are ok but relying on IE/Outlook/Office APIs/tools is not, or make the backend itself modular as to what combination of programs a person used. Or I am sure you could find a way to use the systems default browser or the default mail client using the OS provided apis/tools.

Other than that H@t Trick likes this idea!

[boyska]

Thanks to a bit of magic, you could for example add the MSOutlookData backend (that will, for example, get detailed information for your contacts) or the KDEWallet (that will be useful when saving passwords)

MSOutlookData? Forgive me for being a bit of a noob on this but that sounds like relying on a MS API (is that the right term in this case?),

Clarified that I just wrote the first thing that came on my mind, relying on a MS API is not so different than relying on Qt libraries for a gnome user If he doesn't have/need, he won't use it

The current design IS modular, so you can integrate it with any app (for example you could have KDE (for the wallet) +Thunderbird + whatever ). In this, backends are different from frontends, because you can "add" more of them: it's like a multiple inheritance, but you can choose it at run-time.

Other than that H@t Trick likes this idea!

Glad to know that

@kakaroto

great idea! and keep it up.

p.s.: I like the PoC.. the decorator idea is nice!

Wow, I wasn't expecting so much success!