TB:NG or Not. General Questions -- Decisions needed
Coming back to the August discussion about further TB improvements vs
TB:NG /(/see below /two snippets /and/[Maildev List] with \1\ and \2)/
After last years university Thunderbird/Addressbook project -- which I
had the pleasure to support -- I took the change to use the students
base to drive it forward, a bit in the sense of Joshua's words (see also
below) ...
/We absolutely need some path forward that lets us get these features
in soon, and waiting on a rewrite, or even rebuilding our architecture
for that rewrite, does not seem like the right path forward. /
... which are two-fold.
Yes,
the /vContacts//project \4\ /-- a total new write including to
replace mork with indexedDB, using REACT for UI design -- is somehow
that path forward,
but
it lacks with a general TB design/architecture decision.
For a project like vContacts with the idea in mind to prove concepts
for a TB:NG design/architecture decisions should be essential. But
there isn't.
The open points are (just to name of few)
-- database or 'simple' JSON (as Mike Conley suggested \5\ ),
-- api for the db to communicate with multiple 'consumers',
-- is a individual/dedicated server a possible solution here,
-- how to communicate with external 'consumers' (for contacts
think about GContacts, fruux contacts, mobile devices)
Ben has written a first architecture document/sketch \3\ and there are a
few first discussion on Maildev List in August, but that was only a
short start. There should be more and clearer decisions.
What is the mindset of the Thunderbird community, the council, the
technical stake holders?
For me at the moment it's a question how to proceed with vContacts.
There are many points very much related just to a new Addressbook, but
furthermore there are general questions:
- What is the intention to drive Thunderbird forward?
- Does Thunderbird has or plans to have an architect?
- Is there a settled mindset about those points?
Comments, please.
Thanks
Günter
1\ 10.08.2017 The next phase of Thunderbird development and TB:NG
in <maildev@lists.thunderbird.net>
2\ 15.08.2017 Thunderbird: Next Generation in
<maildev@lists.thunderbird.net>
3\ Ben Buksch https://wiki.mozilla.org/Thunderbird/NextGeneration
4\ Current vContact status can be found here:
https://neandr.github.io/vContacts/Readme.html
/It also includes a link for the XPI to install directly on TB.
vContacts is able to import TB/LDIF exported contacts for testing
(without writing back to the current TB/AB)/
5\ Mike Conley https://github.com/mikeconley/thunderbird-ensemble/wiki
On 10.08.2017 12:35, neandr wrote:
+1 to R Kent's words.
And I would like to take the following compromise position and his
suggestion:
On 8/10/17 6:18 AM, R Kent James via Maildev wrote:
There is one possible compromise position. That would be to focus
initially on some projects that would improve Thunderbird, but would
be code that would be usable in a TB:NG. One possible candidate for
that would be a rewrite of our front-end thread pane, but that is
only a suggestion, there might be others that are better options.
Those projects might also help us to gauge how difficult it will be
to rewrite subsets of Thunderbird without redoing the design from
scratch.
Also I'm not that a virtuous softworker as others on the list I took
the chance to support the group of students at the Victoria University
of Wellington for a new TB/Addressbook. It was developed with the
mindset to overcome mork (replace with db) and to use modern
technology for the software design (html5 and friends, using react).
It was designed as a standalone solution which could be extended later
to be adapted to the mature TB or a future TB:NG.
At least the project delivery a good impression about the obstacles
and chances for such a move.
Currently I'm working to improve the project and it's a good time to
think about bringing it to the table. For further work and direction
the project needs some very elementary decisions, points like:
-- technology base (html5/react, db, how to handle and migrate classic
XUL calls, using linting .. up to: is it necessary describe a typical
dev environment to support volunteers better for a startup helping TB),
-- how would the UI be designed (follow mature TB or take a modern
design approach)
-- should a new TB/AB be offered as an alternative alongside the
classic AB .. and also as a standalone solution with the idea to
support other platforms (mobile world)
FMPOV this project could be helpful to find answers for a lot of the
pending questions around a possible TB:NG approach.
On 10.08.2017 18:28, Joshua Cranmer 🐧 via Maildev wrote:
...
There are some features that we lack that are utterly
inexcusable--CardDAV support first and foremost. We absolutely need
some path forward that lets us get these features in soon, and waiting
on a rewrite, or even rebuilding our architecture for that rewrite,
does not seem like the right path forward.
Very little of our codebase is in such dire condition that it is
outright unmaintainable, although there is somewhat more where the
current API impedes improvement. On the other hand, the chief problem
with TB:NG is that it envisions an end-goal that is still unclear. At
the moment, it's possible for me to initiate a discussion on how to
improve, say, our database API to allow for multithreaded,
asynchronous access. It is possible to make improvements to our
codebase right now, and possible to guide contributors to areas they
could help improve. Meanwhile, if someone wants to start working on
TB:NG, where do we point them?
...
I would not let discussions about future directions hold back progress
with your project. You just have to find what works for you.
The council hasn't announced any specific decision about the technical
future. What has been announce is that we'd want to move towards using
web technologies. The rewrite-from-scratch proposal by Ben, I'd say do
not have a majority support at this time. We haven't formally voted
because there is nothing to vote about. Thunderbird just doesn't have
the financial resources to pull the total-rewrite through, and that is
IF the plan would have the moral support. Technical things aside I think
such a move would be extremely difficult on the community side of things
- trying to re-root people into another completely different
product/codebase.
I guess you could say no news is also news. A gradual rewrite into web
technologies is something we can pull off over time.
-Magnus
On 04-11-2017 00:55, neandr wrote:
Coming back to the August discussion about further TB improvements vs
TB:NG /(/see below /two snippets /and/[Maildev List] with \1\ and \2)/
After last years university Thunderbird/Addressbook project -- which I
had the pleasure to support -- I took the change to use the students
base to drive it forward, a bit in the sense of Joshua's words (see
also below) ...
/We absolutely need some path forward that lets us get these features
in soon, and waiting on a rewrite, or even rebuilding our
architecture for that rewrite, does not seem like the right path
forward. /
... which are two-fold.
Yes,
the /vContacts//project \4\ /-- a total new write including to
replace mork with indexedDB, using REACT for UI design -- is
somehow that path forward,
but
it lacks with a general TB design/architecture decision.
For a project like vContacts with the idea in mind to prove
concepts for a TB:NG design/architecture decisions should be
essential. But there isn't.
The open points are (just to name of few)
-- database or 'simple' JSON (as Mike Conley suggested \5\ ),
-- api for the db to communicate with multiple 'consumers',
-- is a individual/dedicated server a possible solution here,
-- how to communicate with external 'consumers' (for contacts
think about GContacts, fruux contacts, mobile devices)
Ben has written a first architecture document/sketch \3\ and there are
a few first discussion on Maildev List in August, but that was only a
short start. There should be more and clearer decisions.
What is the mindset of the Thunderbird community, the council, the
technical stake holders?
For me at the moment it's a question how to proceed with vContacts.
There are many points very much related just to a new Addressbook, but
furthermore there are general questions:
- What is the intention to drive Thunderbird forward?
- Does Thunderbird has or plans to have an architect?
- Is there a settled mindset about those points?
Comments, please.
Thanks
Günter
1\ 10.08.2017 The next phase of Thunderbird development and
TB:NG in <maildev@lists.thunderbird.net>
2\ 15.08.2017 Thunderbird: Next Generation in
<maildev@lists.thunderbird.net>
3\ Ben Buksch https://wiki.mozilla.org/Thunderbird/NextGeneration
4\ Current vContact status can be found here:
https://neandr.github.io/vContacts/Readme.html
/It also includes a link for the XPI to install directly on TB.
vContacts is able to import TB/LDIF exported contacts for testing
(without writing back to the current TB/AB)/
5\ Mike Conley
https://github.com/mikeconley/thunderbird-ensemble/wiki
On 10.08.2017 12:35, neandr wrote:
+1 to R Kent's words.
And I would like to take the following compromise position and his
suggestion:
On 8/10/17 6:18 AM, R Kent James via Maildev wrote:
There is one possible compromise position. That would be to focus
initially on some projects that would improve Thunderbird, but would
be code that would be usable in a TB:NG. One possible candidate for
that would be a rewrite of our front-end thread pane, but that is
only a suggestion, there might be others that are better options.
Those projects might also help us to gauge how difficult it will be
to rewrite subsets of Thunderbird without redoing the design from
scratch.
Also I'm not that a virtuous softworker as others on the list I took
the chance to support the group of students at the Victoria
University of Wellington for a new TB/Addressbook. It was developed
with the mindset to overcome mork (replace with db) and to use modern
technology for the software design (html5 and friends, using react).
It was designed as a standalone solution which could be extended
later to be adapted to the mature TB or a future TB:NG.
At least the project delivery a good impression about the obstacles
and chances for such a move.
Currently I'm working to improve the project and it's a good time to
think about bringing it to the table. For further work and direction
the project needs some very elementary decisions, points like:
-- technology base (html5/react, db, how to handle and migrate
classic XUL calls, using linting .. up to: is it necessary describe a
typical dev environment to support volunteers better for a startup
helping TB),
-- how would the UI be designed (follow mature TB or take a modern
design approach)
-- should a new TB/AB be offered as an alternative alongside the
classic AB .. and also as a standalone solution with the idea to
support other platforms (mobile world)
FMPOV this project could be helpful to find answers for a lot of the
pending questions around a possible TB:NG approach.
On 10.08.2017 18:28, Joshua Cranmer 🐧 via Maildev wrote:
...
There are some features that we lack that are utterly
inexcusable--CardDAV support first and foremost. We absolutely need
some path forward that lets us get these features in soon, and
waiting on a rewrite, or even rebuilding our architecture for that
rewrite, does not seem like the right path forward.
Very little of our codebase is in such dire condition that it is
outright unmaintainable, although there is somewhat more where the
current API impedes improvement. On the other hand, the chief problem
with TB:NG is that it envisions an end-goal that is still unclear. At
the moment, it's possible for me to initiate a discussion on how to
improve, say, our database API to allow for multithreaded,
asynchronous access. It is possible to make improvements to our
codebase right now, and possible to guide contributors to areas they
could help improve. Meanwhile, if someone wants to start working on
TB:NG, where do we point them?
...
On 04-11-2017 00:55, neandr wrote:
-- database or 'simple' JSON (as Mike Conley suggested \5\ ),
JSON is likely ok too, but IndexedDB will be easier to deal with and
have advantages of not having to load the whole db into memory all the
time, so I'd go with that.
-- api for the db to communicate with multiple 'consumers',
Put the API to operate on the database in a jsm, make sure the methods
all return Promises? Modules are loaded just once and it would be
accessible to all consumers. "Real" sharing of state/data between
windows is not really webby so I would assume that's not part of the deal.
-- is a individual/dedicated server a possible solution here,
I wouldn't rule out something like an internal server in the future.
Accessing data through our custom mailbox protocol has many problems...
Doesn't seem like an internal server would happen very soon though, and
for address book it's likely not needed.
My 5c.
-Magnus