r10s
commented
6 years ago I guess it's also ok to stick to the DCEVENT prefix for all of the mentioned events.
i would leave the prefix as otherwise there may be easy confusion with related flags, types and so on. also it is easier to write a script that greps for all events to put them to other language defines.
Currently delta-core emits useful information (for testing and i think also for UIs/bindings) as
DC_EVENT_INFOcallback items. Also it emits all kinds of debugging information you only sometimes need (smtp/connectivity checking etc.) as the same event.For example, regarding messages I suggest as new events in the format eventname, data1, data2:
DC_MSG_SEEN <msg_id> <info message>DC_MSG_READ <msg_id> <info message>DC_MSGS_DELETED <array[msg_id]> <info message>(more message related ones i guess)
DC_IMAP_DEBUG <> <info message>the several imap connection related infos``DC_SMTP_DEBUG <> <info message>the several smtp connection related infos ``DC_IMAP_IS_OPERATIVE <emailadr> <connection-string-with settings>this means, ssl-connection, and login was successful, we can execute imap commands.DC_SMTP_IS_OPERATIVE <emailadr> <connection-string-with settings>this means, ssl-connection and login was successful, we can send mails over smtpI guess it's also ok to stick to the
DC_EVENT_prefix for all of the mentioned events.These all can mostly just replace existing DC_EVENT_INFO messages, but use the same c-machinery for emitting events.
I suggest to introduce these renamings step by step, along with python tests so we not only document their behaviour/emission but also ensure they continously work.