-
-
Notifications
You must be signed in to change notification settings - Fork 0
/
account.txt
1931 lines (1524 loc) · 47.7 KB
/
account.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
test sample configs with Valgrind, ASAN, UBSAN, Coverity
rename sub to cfg? clearer meaning?
Context - paths, counts
Header[] list -> Env, Body, etc
Incoming -> Buffy[] (paths, counts)
Buffy 1/mailbox
no concept of account
Incoming becomes Account list
Account: imap server, maildir, notmuch, nntp?
account list: imap1, imap2, notmuch
Account named
who owns the context?
where is the config attached?
Account1
mailbox[] (nested?)
Account2
mailboxes
Account3
mailboxes
62 functions use the context
22 functions use incoming
Context
Connection
Account
Mailbox
ConfigSet
Each host needs private data
NeoMutt - Config/globals
Account (default)
Account (specific)
imap, pop, maildir, notmuch, etc
Mailboxes (ref counted)
Emails (ref counted) (Header, env, body, etc)
Account data private
mxops
Where do patterns, limits, tagging live?
On context (a mailbox *view*?)
Who uses Context, when a Account/Mailbox would do?
Context is a *view* of a mailbox
who owns the views?
Mailbox should own headers, etc
(id|subj|label) hashes
View has thread, tree/sorting data
Who owns Accounts?
global to start with
AccIncoming
Account
IMAP 1 server/port/user combo
POP 1 server/port/user combo
Maildir user configurable set of folders (mailboxes)
NNTP 1 server/port/user combo
Notmuch 1 notmuch database
data, free_cb() + some fields common to all, name
Where do unsubscribed folders live?
not all Account's mailboxes are visible (subscribed/in sidebar)
Acc needs inherited config info -> separate object?
Config/Account -> Local Config
unaccount - closes connection, mailboxes, etc
Auto Accounts - Imap, pop, notmuch, nntp
how does 'account' command fit in?
mailboxes -> current 'account' NO -> default, YES use it
none -> 1 Account incoming underneath
full auto -> find_ac(folder) -> folder not enough
need user, host, port
account-ish config have user -> imap_user, what if they set A:imap_user?
account/set folder spoolfile, postponed, trash, record
use status bar to show their values, NO, not dynamic
need changed-account notification (account-hook) -> redraw
examples in 4 languages to highlight folder names (1 CJK)
NeoMutt object
Config
Connections
Context
Threads
AccountList
Account
MailboxList
EmailList
Env, Body...
Mailboxes M
ask MXAPI for type of M
search As for owner?
or use A from config (if compatible)
or create new A (uniq name)
Add M to A
How does A test for M's membership?
*same* type (magic), $folder [user,host,port]
login_cmp()
or mx_cmp() -- let *it* canonicalise $folder and compare login
Compare needs canon mailbox: have $folder, mailbox
path_canon($folder, mailbox) -> canon_mailbox
NO needs login
pretty_path(A, ...) what's needed?
URL syntax:
account://NAME/rel-path
or
mailbox://ANAME/rel-path
or canon
imaps://user@host:port/rel-path
abbreviate to:
a:// or m://
Account NAME
set folder, imap user (pass)
mailboxes
folder could be '/', or empty or full path
X_{user,pass,login} -> {user,pass,login}
config name clash?
NO folder needs to be full else don't know which type the mailbox is
API mx_check_empty(path) -> bool - local use only
or just open it?
API has_new_mail(path) - need to identify it first
∀ mailboxes - find by path, is notmuch, realpath, complex
test empty, insert, remove, free
A is typed if all children are the same type, e.g. Notmuch
change functions to take a MailboxList (rather than a mailbox)
UI creates list of one (for single selections)
or a multiple for tagged
thus centrlising tagging logic
MailboxList or HeaderList
Header*View* is_tagged, etc can't be List
needs to be sortable
can we have *both*, Incoming and AccountList?
How do I move Context inners to Mailbox?
Mailbox set, find -> obj + type
set trash = "x://path"
later resolve_mailbox($trash) -> lookup
find it, update ptr. !found -> get type
Account -> Mailbox -> Email
path, (type?), Mailbox?
allow utf-8 account names?
only forbid ':' scope separator
store as punycode?
store as b64-encoded?
something to allow all characters
ac_get_str(A, IC_X) -> ptr to var
what if someone changes it? crash!
have a magic Account for temporary mbox files?
when opening a folder from, what path string do we get?
sidebar - full path
browser - full path
typed in - relative to current folder/account
C)ontext, A)ccount, M)ailbox, H)eader, T)hread
Move headers from C to M
H array, ref-counted
C has Thread hashes (belong on M?)
Move C hdrs, but not v2r (that's *our* array)
First separate H from T?
could we leave T in H to start?
Does the H need to know:
a) it's in a T?
b) which T it's in
H Header no, UH User-Header YES
Does the UI want to work with UH which has T info, tagging, etc?
HV HeaderView
C has HV[]
T is tree of HV (ptrs to H)
C needs to become MV (MailboxView)
Index, Pager wrt H
Who owns C, pass it down through functions
29 uses of Incoming
734 uses (82 functions using) Context
N -> AL -> NL -> EL (HEB, etc)
V)iew
L)ist
Index (MV), Pager (EV), Sidebar(AV) - viewers
MV has M, EL (subset of M's)
EL node (tagged, deleted, etc), sort
EV has E, cahced text, colour info, view info
AV has AL (subset of N's) current A, M, sort info
base object for all has
type
refcount
bool deleted (or similar)
sidebar
AV - $acc_view, $sb_sort
MV new-only, sort
SB maintains: highlight/selection, window view
index
MV one mailbox
EV tagging, limit, sort, threading, current selection
Pager
EV one email - local (per email settings)
Index fmt uses I's MV, EV?
Status bar uses I's MV info
Pager bar needs I's MV info for (email x of y)
needs P's EV for subject, %age through email
mx_open() open and attach to (create if nec.) account
NO already done
config -> account tree
open M, not ready, open A, open M
Open A notify, e.g. sidebar A(red) -> A(green)
Open M notify sb -> active M, Index clears
Get Es notify -> Index populates
that's probably the index doing the work
Open E notify whom?
Can the status bar *not* exist - just run on notifications. NO!
A name
mailboxes x y z
set folder
set imap_user
set imap_pass
set spoolfile
set postponed
set trash
set imap_list_subscribed
need default A type unknown, unnamed
'account' named A, type unknown [CREATE-A] (to AL)
set folder -> local config (imap_user, pass, etc, too)
mailboxes x y z relative to local $folder [ADD-M] to (to A)
=> type -> IMAP
if mailboxes other:// type add to default (one type / A)
M has ptr to A (needed for cfg, etc)
chdir to PATH -> as As for a match
A.match against local $folder NO match -> fail
search through existing M [ABCDE] subscribed
or
create new M [G]
or
browser open / sidebar open
M: last update: never
A: state closed
mx_mbox_open(M) -> imap_acc_open (M -> A)
imap_acc_open(A) -> socket, conn stuff
get mailboxes? if so, update statuses of Ms
M: UNPOP, POPULATED, NOT_EXIST - notify
open(M) -> imap_mbox_open(M)
if (!exist) error
if (POPULATED) done
UNPOPULATED
get email IDs; notify (may be in hcache)
"open" is too wide: need
list new
list all
get headers (list)
get struct (list)
get body (list)
get headers -> EL
each with state
HEADER -> notify
get in reverse order (newest first)?
notifications on ...?
N, A, M, E with recursive flag
Index watches M+ (recursive)
Pager watches E
Sidebar N+
Events NEW, CHANGED, DELETED
Do objects need an IWatchable interface?
tough for the N object (not refcounted)
backends:
imap, pop, maildir(mh), mbox(mmdf), nntp, notmuch, compressed
ctx->data: pop, nntp, imap, mh, nm,
hdr->data: nntp, nm, imap, pop (idstr)
1 empty A per M if no <account>
struct naming?
VMailbox (view)
LAccount (list)
abstract the mailbox?
add/remove()
find_by_id()
find_by_path()
keep count
mbox -> array for views?
slab allocator / factory ∀ myriad small objects?
unify all private data {new,free,init,get}_X
multiple notifications: let the receivers know what's coming
start(uniq id, expected count)
count * notify()
end(uniq id)
receivers can ignore some as long as they listen for `end`
drop mailbox_free()?
use mbox_close
create header_free() ∀ mailboxes
should we steal account-hook <set> commands NO
POSSIBLY -- if we have a *named* account
and a matching hook
∀ backend, mailboxes - no info existing M, existing A?
imap <mailboxes> imaps://apple.com/aardvark -> M
<mailboxes> imaps://apple.com/beaver
empty new M, open -> new A done
$folder + <mb> - path -> dummy A, no name, no type
match -> attach, not -> create & attach
A has no config for backwards compat
<a><mb> apple banana -> 2*M -> A
A is incomplete, but has config
set user,pass -> A
adding to A -> need sibling test?
how would that work for maildir? can't NO
open M, have A has type,config, still run A-hook
open A
how do we list all of M?
0 named A -> iterate through ML as <mb>'d
1+ named A -> <a> used -> assume always
iterate through AL, then ML
sb_sort = A:alpha,M:new,M:alpha
if A: missing, don't display -> only M? complicated
if A: missing, don't sort A at all
sb_display_account [LIST] of A
maildir: <mb> a b c (no A specified) use dummy?
open 'b' don't need A, so continue using dummy
dummy means *AL*, ML, always
maildir <a><mb> a b c named A, grouped config
only create dummy when needed?
simple case only 1 A
sb_display = A1,A2,A3
empty => all
+=, -=
!= (toggle?)
no advantage to displaying nothing!
turn off sidebar
nm A matched by db path - contents of A just <mb>
nntp A matched by user,pass,host -- all subscribed groups
nm - param to name query? -> desc or
<sb-subscribe>
<sb-desc-folder> / <sb-name-folder>
to make it session-permanent
mailbox_free -> separation between close and free?
needed?
close -> maybe a reopen
free -> DEAD forever
open on Imap A -> LSUB & <mb>
A types:
MboxA - name, config, data (->conn)
ConnA - user, pass, port, host, etc
(cfg)A - config
Imap -> Connection (stacked), Mbox, Nntp too
maildir -> NULL, compresse too
notmuch -> db info
how much M->data can become A->data?
A-data
M-data
E-data
data-free will close connections if nec
hcache is opened at parse time -- how long is it kept open?
keep as A-data, keep open? YES
change mh_data() to get_mh_data() -- so it isn't mistaken as a cast
E-data
pop: uid
nntp: article num
imap: flags, uid
nm: uid
md: none (flags?)
mbox: none
comp: none
mxapi: create compare function which uses backend-specific id
check POP uid in hcache, refno too (meaning?)
mx_open(imap://) (no folder info)
find A -> need backends to do matching
take host, user, port ito account (net backends)
take dir into account (maildir)
no A for md -> base dir of '/'
split up mxops into A, M, E versions
A:
path*
mbox_open*
msg_padding
M:
msg_open*
mbox_check/sync/close
E:
tags*? or M?
msg_commit
msg_close
do all X ops really want to happen on parent(X)?
so that... what?
notifications?
client shouldn't know/care
M might cache tags on E
but that knowledge should be private to backend
E has ptr to M
*it* should do *that* work
close() on X, open on parent(X)?
is this the exception?
who probes the first path?
we don't have an A
have NULL A ∀ backends?
A(NULL)->probe(path)
if probe isn't in mxapi, who has list of probes?
does probe return an A?
no, not enough info
how do the backends get access to Config?
don't want to use a global
need main Config ptr to create A-specific Config
------------------------------------------------------------
who owns AL?
int mx_mbox_open(M, flags);
M partially filled Mailbox, requirements are backend-specific
int mx_mbox_open(AL, M, flags);
backend doesn't need to keep any objects
or need access to any globals (except its own)
------------------------------------------------------------
mailboxes a b c
a,b siblings, c different
create dummy A0
create one M per path
probe path to get TYPE
attach to dummy A0
open M(b)
run A-hook (only set global config)
needs to be run by mx.c
has real A? NO
find matching A: FAILED
open A
create A1 (unnamed, no config)
connect to server
populate A1
populate M (using A1)
open M(a)
run A-hook (only set global config)
needs to be run by mx.c
has real A? NO
find matching A: MATCHED - A1
using user,pass,host,port
populate M (using A1)
open M(c)
run A-hook (only set global config)
needs to be run by mx.c
has real A? NO
find matching A: FAILED
open A
create A2 (unnamed, no config)
connect to server
populate A2
populate M (using A2)
------------------------------------------------------------
account apple
mailboxes a1 a2 a3
create ML with A=apple
open M(a1)
run A-hook (only set global config)
needs to be run by mx.c
has real A? YES
is open? NO
open A
create A1 (unnamed, no config)
connect to server
populate A1
populate M (using A1)
open M(a2)
run A-hook (only set global config)
needs to be run by mx.c
has real A? YES
is open? YES
populate M (using A1)
mbox check_all should happen at A-level (for efficiency)
config: use synonyms and inheritance for A:user -> imap_user mapping?
--------------------------------------------------------------------------------
parse_mailboxes
nm_path_probe, nm_normalize_uri
mutt_expand_path(_regex)
imap_path_probe
imap_expand_path
imap_parse_path
imap_conn_find
mutt_conn_find
mutt_account_hook
mx_path_canon (^-expansion)
mx_path_probe -> path_canon
nm_path_probe
mx_path_probe
mx_path_probe
--------------------------------------------------------------------------------
mailboxes + folder -> Mailbox
expand using $folder, $HOME
if expansion fails, mailbox is errored and dropped
backend may use "user", "login", "pass"
DON'T search for A, or attach an A
=> Mailbox (partial)
NO user, login, pass info lost => NEED A
=> find_A with partial info
reason for Username, ImapUser checks (account_match)
imap://user:pass@host:port/path
when matching mailboxes should search in reverse order
(most recently defined matching mailbox wins)
store login, user, pass on A, give ptr to Connection (shorter-lived)
auto A mailboxes:
imap: LSUB subscribed
nntp: newsrc
maildir: how? flat search, or recursive option?
notmuch: how? saved/pre-defined queries - how to we get them?
--------------------------------------------------------------------------------
mailboxes +name
expand using $folder, $HOME (or die) => Mailbox (partial)
find_A(M) or mx_find_A(M) -> mx_new_A(M?)
flag for new? when else will we need a new A?
new_A creates A and adata - need new for *name* of A
backends might have different Config overrides
--------------------------------------------------------------------------------
Mailboxes - new uses for path, realpath
rename realpath to canon_path - contents BE-specific
if !A then path = canon_path, except for compressed
if A, then canon_path is canonical and path is pretty
relative to A-$folder (except compressed)
Internally convert =folder to +folder?
A_find_M(path) uses global AL (for now)
Does imap canon path contain user,pass,login,port?
if there's a specific imap_find(), then no (only if A)
what do we display to the user?
what if two M differ only by user?
Account syntax? A-name +folder - apple:+folder
should *this* be shared in path? ON
if folder is in root of A-apple, then apple:folder is ok
":+folder" relative to current M/A, equiv to "+folder"
canon path - "user" always, "pass" never, "login" if set, "port" if non-standard
A-$folder set to /a/b or imap://a/b - stored as what?
login info stored in A->data.conn
$folder stored in A->config
accept /a/b store as imap://a/b
expandos for canon_path, pretty_path, A-name too
short_canon too? no (user,login,port) or make canon expando smart?
when creating a new A, check others to determine which attributes
make a path canonical (user,login,port) -- NO confusing
Mailbox/mbox path = user entered path, tidied up
canon_path = realpath() of path
pop/nntp like imap
notmuch - path nm://query
realpath include db path
WON'T be a !A (it'll always be present) only an UNNAMED A
--------------------------------------------------------------------------------
mailboxes X
(relative|canon)
A(exists|missing)
account cmd?
1)
canon(X)
probe(X) => magic, ops
2)
if (A.cmd) use A
if (BE->find_A(X)) use A
else BE->create_A(NULL)
3)
BE->find(A,X) -> M
error exists
else BE->create_M(X) -> success
ac_add(A,M)
mx functions?
account_find(path)
mbox_create(path)
ac_add(A,M)
ac_remove(A,M)
ac_function - names clash with Config
ac functions above mbox functions in API
"account apple" - don't know typ until "mailboxes"
if current A, close existing? NO
or have mx_ac_free(A)? NO
account_create(name) -> A(empty)
--------------------------------------------------------------------------------
mbox_create(path, canon, magic)
set magic, path, realpath
ac_create(name) set name, init config (no name => set neither)
ac_create(path) NO, ac_add(M) instead
ac_add(A,M) -> A check/set type, add M, link objs
ac_remove(A,M) -> unlink, remove M
ac_find(A, path) ∀ M do BE-specific M-compare(M, path)
who add A to BE list? when?
ac_add(A,M)?
does BE need a private list?
not to start with
do we need Connections? they're not shared between BEs
have a 1s timer call to all BEs
let them implement keepalive, etc
save escaped (munged) imap mboxname in Mailbox->data (priv)
mx_mbox_find(path, flags)
uses Folder to expand // probe to identify(delegated to BE)
or A_find_mbox(path, flags, **M, **A)
returns M or new M or NULL
should it create M?
should it create A?
should it *open* A?
how many functions can be called 'cold' with just a path?
few? 1 change_folder()
create_mailbox(have A)
2 routes
notmuch
entire-thread -- new mbox
vf-from-query -- possible new mbox
window-back -- alter existing mbox and refresh
window-forward -- same
other folder
change-folder
nntp -> existing mbox, or not
what if A doesn't exist?
mbox_open ->
first find and refresh
else find A and open
else open A, open M
do we need *A* check for new mail? we'll already
or by A then M. if A_check succeeds, next A, else ∀ M
imap sends separate STATUS. any advantage to A_check?
(over n*M_check)? sorting?
maildir A - unnamed => root is /
named - who sets root? when?
account apple [ARGS] -- passed to ac_create?
interferes with one-liner account NAME commands
set folder = /x/y - trap this? and set root? how?
when we A_add_M(M) select root?
if named, what do we select?
what's the root of each BE? (named vs unnamed)?
pop,imap,nntp - (host,user,port) (named or unnamed)
mbox,compressed - fixed, so irrelevant -- 1 M per A
notmuch - db - fixed
maildir
unnamed -> root is /
named but no A-$folder -> root is /
named and A-$folder -> root is A-$folder
sidebar_account=X,Y,Z
missing accounts not hidden, just collapsed?
or sidebar_collapsed=X,Y,Z
dropping "imap_" means $folder MUST come first
else we don't know the BE type
when we 'c'hange folder and <tab> complete
can we preserve M (as we know it)
--------------------------------------------------------------------------------
MAILDIR
set folder=/x
mailboxes =y
1) no A, no M
2) A, diff M
3) A, same M
1) (canon, probe), wrap in M, find A, create A, add M to A
2) (canon, probe), find A, find M, wrap in M, add M to A
3) (canon, probe), find A, find M
Need to canon? NO just expand $folder NO
then probe for magic
∀ A call A_match_path(P) -> need canon
16 calls to mx_mbox_open - most know M (or can find it)
int mx_mbox_open(M*, flags) NO parse_mailboxes
if (!canon) canon(M), sets magic }
if (!magic) probe(M), sets magic }- move it inside functions
mx_find_A(M) 1) NULL, 2,3) A
1) create A(magic), set A's magic
2,3) A_find_M(M) 2) NULL 3) M
2) A_add_M(M)
mx_find_A(M) use magic, call BE->A_path_match(M->canon)
M = A_find_M(A, M) ∀ A.ML use BE cmp, do what on match?
A_add_M(A, M) add M to A.ML, set links
A_find_M(A,M*) -> error, no match make replaces M
--------------------------------------------------------------------------------
move mxops to A?
most ops need M, not ctx. ctx is a view for UI only
canon includes decorations: imap://user@
path is just server-local path
move all dot_dump nec headers to BE_private.h
change backing for config vars:
$mbox, $postponed, $record, $spoolfile, $trash
what about $folder?
to type Mailbox
need new config type
find/create M, attach to A
how do M's build deps fit in with Config?
attach smtp Connection to NeoMutt object -> smtp_init(), smtp_shutdown()
or does smtp belong at A level -- one per A, or global?
$smtp_url, pass, authenticaors - A-specific
--------------------------------------------------------------------------------
path is user specified - what if they specify decorations?
real/canon doesn't exist M-specific (possibly split up)
M comparisons done by BE
path completely undecorated -> use "named" mailboxes if not suitable
with IMAP delim of '.' should the path be '/' delimited? for ease of other code
path is tidied and undecorated
what about full path for status bar -- need realpath + decorations
path relative to root
canon - fully qualified & real, fully decorated (excluding default ports, etc)
--------------------------------------------------------------------------------
standard functions ∀ BE
vars: adata, mdata, edata
fns: BE_DATA_{free,new,get} (in this order)
vars: a Account, m Mailbox, e Email, ctx Context (will be mv)
@extends ∀ Xdata
create an A-check ∀ notmuch M => one db open, close
view obj automatically watches data obj
struct Mailbox *m ∀ src
adata and mdata should be private!
BE_separate msg, hcache srcfile? what else?
CurrentNewsSrv (kill this)
check all ac_find() work, multiple A ∀ BE
Connection's account info ptr *const*
Add Buffer ptr ∀ mxapi - aim to remove all mutt_error!
"INBOX" string 15 * in IMAP
revert '=' to '+' conversion? option?
account-hooks not fired
eliminate "ImapMbox" - what's its use?
change conn_close to ** free
*imap* complete_hosts is effectively complete_A() ∀ BE?
--------------------------------------------------------------------------------
A-hook - when is it called?
only on first M open - keep credentials
just before adata_new()
folder-hook on every M
match against
realpath
path
description
change A hook to take (M)
what does F-hook need? same?
what about after M-close? or reconnect after conn loss?
so ∀ M open -> A-hook, F-hook NO
only if actually need to reconnect - when?
BE_something() -> first check conn
get_adata() -> (re-)open conn -> A-hook first
--------------------------------------------------------------------------------
option $dont_close - don't mbox_close on leaving
for check_all, do we need to run A-hook each time?
only for lost connections
∀ BE_parse_path -> path -> ConnAcct - where? add tests
pop_fetch_mail doesn't use Context - assumes 1 host
if ctx, use it
if !ctx fetch all pop hosts?
if !PopHost - fetch all pop BE
only BE can set/change realpath(canon)
if path is undecorated, is path == realpath + strlen(imap://) ?
not always - compressed BE will differ
A-config browser folder_format - per A?
sort_browser too
A-config sidebar_format - per A?
sb blocks?
sorting?
--------------------------------------------------------------------------------
Mailbox Orphans
browser - store paths as Mailbox - need refcounting first
orphan M ∀ $paths like WeakPtr - resolve as needed
$folder, ^, etc resolved, then M is canon'd, has magic too
gets M ptr when ref-counted, A-ptr useful too (ref-counted)
orphans need listener (cs, he, name, ev)
he is ConfigDef
orphans will rely on M->path being char* (not an array)
point orphan config vars to &M.path
listener triggers probe, tidy, canon
=> config doesn't need to know about M
listener needs to convert &M.path to &M where path may not be first member
offsetof macro?
is orphan an M or a struct { path, M* }?
can't be M, because it needs to be able to be NULL
M*? makes config setting awkward
M is OK, because M.path can be NULL
flags = ORPHAN
all mxapi fns do
M = orphan_resolve(M)
have
M* (orphan) resolve
M* (real) No A*
MV has WeakPtr (Orphan) to last used E
path_pretty -> path_tidy?
just the path section of (real)path
if imap:// then /, otherwise IMBOX?
parse_mailboxes -> path & realpath
folder-, account-hook -> realpath
M* path_wrap(P) p->path, canon(P), probe first, tidy(path)
account-hook canon, since matche to realpath (start)
is canon needed? OR BE-A-match?
so that imap://host matches imap://user@host?
NO, it's a regex
A for possibly non-existent M
A* ac_find_account(P)
that's mostly probe()
find specific M (e.g. resolve orphan)
ac_find_mailbox(A, M) -> M2
should Orphan have A*? YES, lifespan of A is large enough
path_match(M,P) or (P,P)
which path? realpath
mx_resolve_path(P) -> M(P, R, magic, A), orphan flag
ac_add -> !orphan
how do orphans work with inherited config?
any M is final - don't canon/pretty/deconstruct it
mx_mbox_open_path() wrapper?
mx_mbox_open_path()
Trash, Spoolfile or mbox-hook, user, Postponed, save path, tmpmbox, mainfolder
mx_mbox_open() 5 calls using Mailbox
store M as trees
BE knows how, frontend doesn't need to know
get_M(A, flags) -> flat, tree, filtered, etc for MV
check all mxapi params are used, e.g. folder
user path - copy to M->realpath
expand +
canon(M) -> M->path ?
mxapi GUARANTEE
check M->A is set ∀ M in AllMailboxes
VALID(M) macro?
∀ M
M->A exists
M->magic
M->mxops
M->path set and tidy
M->realpath set (canon)
ensure correct magic to match backend
ensure ctx->M is valie
fine for $trash, $record, etc backed by M