Skip to main content ↑ ↓

Topics

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

Topics - Tante

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