Discussion about Web App Thunderbird

Wayne Mery vseerror at lehigh.edu
Wed Apr 10 16:28:47 UTC 2019


On 4/10/2019 8:54 AM, Eyal Rozenberg wrote:
> On 10/04/2019 9:38, Magnus Melin wrote:
>> it's not written in stone that a mobile version could never be
>> created.
> But it is written in stone that we (or rather, you guys) are not working
> towards that end. That is, to my knowledge, the Thunderbird council has
> not authorized orienting the development of Thunderbird towards a mobile
> version (or a web application etc.)

IMO whether mobile or web has been authorized or not is not currently 
the sticking point. The sticking point is we are currently in a position 
of technical and UI debt where we are probably at least 6 months (to a 
year?) away from a) having a stabilized platform base after the bulk of 
the Gecko churn is sorted out (#1 priority), b) we don't yet have the 
staffing to even look at what the future holds, whether it is done with 
current staff that can be reallocated, or new hires. (Several months ago 
it was hoped that this investigation would have already begun, but that 
hasn't materialized.)

In short, discussion today is probably not much more than an academic 
exercise with lots of speculation, and thus time poorly spent.


>> I think that depends a lot on which things you intend to do, and how you
>> do it. What we can say is that we need to take care so that we identify
>> the bottlenecks and optimize them appropriately. I'll point out in this
>> discussion that the pure JavaScript model is also faster since crossing
>> the XPCOM boundaries is comparatively very, very slow.
> 1. Citation needed to back this sweeping claim...

The Xpconnect boundary has been an issue for decades. Old examples  
https://bugzilla.mozilla.org/show_bug.cgi?id=296453#c62 and 
https://bugzilla.mozilla.org/show_bug.cgi?id=413260#c75  I'm sure there 
are more.

Joshua and rKent's would be people who have posted about it more 
recently (last ~5 years).


> 2. That sounds like a reason to consider how to allow for faster
> crossing of the boundary between JS to compiled code (with XPCOM or
> otherwise).

In interesting idea, but of course challenging given the decades long 
history.


>
> On 10/04/2019 9:52, Magnus Melin wrote:> On 08-04-2019 15:55, Tanstaafl
> wrote:
>> When I'm talking about the target of a super fat, privileged web
>> application I'm talking about the technology in the back.
> Yes, so are we (at least, I am and I think I speak for Tanstaafl and
> some otherws as well). Thunderbird should not have this technology in
> the back.
>
> (Personally, I think the technology in the back should go even further
> and even more "server"-y than "desktop"-y. I think I mentioned this in
> the "Vision for Thunderbird" discussion last year, but I'm hoping for
> something closer to a proper database engine for MIME trees and other
> structured data types for messages, with a rich set of operations,
> multiple format backends, compression etc. But I digress.)
>
>> Thunderbird would still be a desktop application just like to today.
> A web app hiding behind a desktopy facade is still essentially a web app.
>
>> That the
>> technology behind would open up other possibilities in the future is a
>> bonus, but not the primary target at the moment since that could
>> easily side track the main developments.
> You're suggesting this _is_ a target, albeit a secondary one. I again
> like to clear this up. Has the council decided that a mobile client, or
> TB-as-a-web-app, is a target of any kind for development work? If so,
> please post a link. If not, please don't let it sneak in by the back door.
>
> Eyal
>
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20190410/468b5367/attachment.html>


More information about the tb-planning mailing list