Plu la malnova redaktilo funkcias per retpoŝto. Oni povus aŭ same adapti ĝin al afiŝado aŭ akcepti retpoŝtojn kaj afiŝi ĉe gist.github.com kaj poste trakti laŭ la nova metodo, aŭ komplete paralele trakti retpoŝtojn kaj afiŝojn.
Aktuale la paralela traktado de retpoŝtoj ŝajnas preferinda:
tio funkcias jam 20 jaroj relative stabila, dum la Api por gist.github.com foje ne estas alirebla. Do per retpoŝto ni ĉiam havas alternativon
Ĉe eraro-arporto oni povas sendi korekton per ordinara retpoŝtilo, kio foje estas plej rekta procedo.
Sed ni devos certigi, ke ĉe erara raktado retpoŝto ne perdiĝu. Estas du eblecoj:
unue legi ciujn retpoŝtojn, trakti kaj nur fine forigi - se tamen duoble ili traktiĝas ni havos kelkajn erarmesaĝojn pri versikonflikto al redaktantoj
ie savi la retpoŝtojn, tiel ke ĉe problemo ni ie havas savkopion
trakti ilin unu post alia. Tiam ni havos nur unu probleman kazon, se la procedo rompiĝas.
Cetere anstataŭ fetchmail, kiu postulas lokan SMTP-servilon(?) kaj poŝtfakon, oni povas legi kaj forigi mesaĝojn, eĉ forsendi ankaŭ per curl (https://everything.curl.dev/usingcurl/uploads) - ni elprovu tion por simpligi la necesan isntalaĵon en Afido.
Plu la malnova redaktilo funkcias per retpoŝto. Oni povus aŭ same adapti ĝin al afiŝado aŭ akcepti retpoŝtojn kaj afiŝi ĉe gist.github.com kaj poste trakti laŭ la nova metodo, aŭ komplete paralele trakti retpoŝtojn kaj afiŝojn.
Aktuale la paralela traktado de retpoŝtoj ŝajnas preferinda:
Sed ni devos certigi, ke ĉe erara raktado retpoŝto ne perdiĝu. Estas du eblecoj:
Cetere anstataŭ fetchmail, kiu postulas lokan SMTP-servilon(?) kaj poŝtfakon, oni povas legi kaj forigi mesaĝojn, eĉ forsendi ankaŭ per curl (https://everything.curl.dev/usingcurl/uploads) - ni elprovu tion por simpligi la necesan isntalaĵon en Afido.