Re: Architecture
Reply #1 –
@Tante, sure, documentation would be useful, as when there i lots of code one shouldn't say that code itself is best documentation. ;-)
How do you intend to implement these features in the future. Are all non-web-protocols crippled implementations like in Opera? What happens, when a user wants feature X in IRC? Sure Opera is a powerful browser, but most features are not for casual users and not for power users, either. (IRC unusable due to incompatibility with bouncers, Mail without PGP, etc.)
Level of support will depend on our (users) needs, "core" should have at least basic support for all stuff that is required for web browsing, but also be flexible to allow to extend it when needed (be modular).
I f user wants feature X (not only in IRC) then he or she should ask developers first, if it will make sense then it could be added to core or module. If it doesn't make sense then someone else could always add it to alternative module (for example create more feature rich implementation of IRC client) which could replace existing one (user would need to install it and select as preferred one).
AFAIK libpurple should give as goo enough support for iRC, but it needs more investigation first (so far I know that there exists bindings for Qt, qpurple).
PGP is one of most wanted features for mail, so it is must have, sooner or later. We will try to find suitable library first, no need to reinvent wheel if something useful would already exist (or it's easy to create Qt bindings for it), possibly asking developers of some existing Qt based mail client to help with it (for example by creating version of such application which could run as module for Otter).
If feature X is implemented in most cases, then we are talking about full-fledged FTP, IRC, XMPP, Mail, SSH, SMB, whatever clients. How does Otter treat this protocol implementations? Should Otter treat these implementations any different than the HTTP(S)/SPDY implementation? What about bugs/crashes? Is it possible that a Bug in the Mail-Client crashes Otter?
What about plugins? What about extensions? Is it possible to modify the behaviour of the IRC-Client?
Network protocols are handled by QtWebKit and QtNetwork, that means that improvements for them should be done upstream (so all users of Qt could benefit from them).
For other protocols is varies, some need only basic handlers while others need more complex solutions (like bittorent integrated in transfers manager).
We could try to separate some modules so they wouldn't take down entire application, it should be doable, one way or another.
As mentioned earlier most of modules (if not all) should be replaceable by other implementations.
And yes, extensions are planned (Firefox and Chrome APIs), but it's something scheduled post 1.0 release.
In my opinion Otter should be a browser in general. Not a "web browser" or a "smb browser" or a "file browser". Just a browser which supports many different protocols. Yes, the focus is HTTP and yes most protocols may be "read only" (like FTP or file://), but the software architecture should support any protocols. Features like bookmarks, history, etc. can be used by any protocol.
It' up to be decided, if it makes sense to go the same way as Konqueror did (and ended up being replaced by Dolphin and rekonq...).
We don't want let users think that Otter is bloated or something like that, it's hard to get it right. ;-)
If I want to add libpurple/IM, how will I do that? Currently everything is pretty much hardcoded, yes? Maybe all of these "modules" should be treated like a dll/so whatever and loaded at run-time? Maybe they should be executed as processes and not as threads to prevent crashes? How are they going to communicate with "Otter"?
Yes, currently it's a bit hard-coded (Window object decides which module should be used) but as soon as it will be really needed (well, obviously we have more important stuff to work on right now ;-)) they will become proper modules, managed by ModulesManager and loaded from DLL / SO files (with exception of basic modules, to ensure that basic features will always work).
It will take some time to make it good enough, but sooner or alter we should find some solution for running them separately. For communicating we could use for example QLocalSocket, if nothing better would show up.
I think these are important questions which should be carefully answered, documented (wiki) and implemented (API), before tickets like #24 can be started. Currently the project is young and many features can be implemented on-the-fly, but in a few years a bad architecture is going to kill any new feature requests.
True, although in case of FTP it's a bit different story, what we need to do there is mostly just to parse output from FTP server, using deprecated QFtp class as reference.
Keep in mind that we are using quite powerful framework (Qt) which implements most of basic stuff, usually in enough flexible form to let to extend it if needed.
Topic: Architecture (Read 4060 times)
