Skip to main content ↑ ↓

Show Posts

This section allows you to view all Show Posts made by this member. Note that you can only see Show Posts made in areas you currently have access to.

Messages - Tante

2
Otter Browser Forum / Re: Architecture
Quote from: Emdek on

@Tante, sure, documentation would be useful, as when there i lots of code one shouldn't say that code itself is best documentation. ;-)

As long as it doesn't stay that way. E.g. Qt isn't as successful as it is, just because it's technically good. It's successful, because it's well documented.

Quote from: Emdek on
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...).

Konqueror was always too much integrated in KDE and focused more on the backend, than on the user interface (KIO, KHTML, ...). AFAIK dolphin still uses many parts of Konqueror (KIO) and attacked the faulty UI of Konqueror. I think Otter is more like Dolphin, which uses existing software to create a good user experience. (instead of developing highly developed backends like Konqueror did. Also I have to admit I don't know how much time has been used to develop the UI and how much time the backends)
And does anyone use rekonq seriously?

Quote from: Emdek on
We don't want let users think that Otter is bloated or something like that, it's hard to get it right. ;-)

What does "bloated" mean? Performance? Users will always say that more features require more CPU, memory whatever, even though these features can be completely disabled (modules not loaded). Used developer time, which could be used to develop "more important" parts? I think users will only complain, if features are crippled, like in opera (there were many discussions in the opera forums in the past). The advantage of Otter is, that it's open source and attracts more and more developers. These developers must be able to easily extend and maintain Otter, like adding a SFTP client (different user interface, different logic, but same goal as FTP, so there is a high probability that such a request arises). These features should be, which might be delivered by a 3th party, very good encapsulated. Maybe something like the linux kernel does with modules.

Just don't wait too long, until you develop a proper "Otter Module System", especially if you want a RSS reader in beta 3.
3
Otter Browser Forum / Architecture
Hi,

just read about Otter a few days ago. I'm stuck with Opera 12.x on Linux (vendor lock-in due to GUI interface, bookmarks, passwords, RSS feeds, ...) so I'm highly interested in the development of Otter.

I've read many tickets/issues on github and several threads in this board. What I'm missing is a general discussion and documentation about the architecture of Otter. (or I still haven't found it, so please excuse me if I missed that one)

As far as I know, Otter should provide most features of Opera + extra. This includes non-web protocols (FTP, IRC, Bittorrent, IMAP(S)/POP3, SMTP, ...), Plugins (Flash, Java, *light, ...) and Extensions (Greasemonkey, Opera Extensions, ...). See also:



On top of that #24 is a beta 2 milestone  :yikes:.

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.)

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?

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.

What I'm saying is, that Otter should be a rich client platform (something like Eclipse RCP/Netbeans Platform; Sorry I'm mostly a Java and C/Embedded Systems developer :love:), which is robust and can be easily extended.

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"?

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.