New library design

[chadell]

TODO

• Simplify data to only one class with several conversion methods
• Take into account that an email can contain multiple notifications (no only Ical), due to multiple payloads
• Check for DRY
• Add init data for Gmail API -> NO NEEDED, we can leverage on Gmail API message directly as it requires multiple calls to dowload attachements, etc., and the parsed don't handle connections, so what we will do is to use the raw option to download the message as a regular email an RFC 2822
• Refactor testing
• Document changes in changelog and readme

The main idea behind this refactor is to make the library more "autonomous" to get all the information that it needs to create notifications. The main change is that, before, a notifications was parsed only by ONE parser each time, now we could combine multiple parsers to get all the information needed.

The workflow would look like:

1. Init the Provider (if no provider type, a standard Icalendar one is offered by default).

from circuit_maintenance_parser import init_provider
ntt_provider = init_provider("ntt")

2. Init the Data to be parsed

raw_data = b"""BEGIN:VCALENDAR
VERSION:2.0
...
END:VCALENDAR
"""
from circuit_maintenance_parser import init_data_raw

data_to_process =init_data_raw("ical", raw_data)

In this case we are using the simples init, but an init_from_email could be used to call the library using a standard Email representation. This way, the library is not closely tangled with a specific data source, and can be reused in multiple use cases, but at the same time offers all the data structure processing, so the library user don't need to take care of.

3. Process the Data using the Provider processor (that is composed by multiple combined parsers)

parsed_notifications = ntt_provider.process_notifications(data_to_process)

print(parsed_notifications[0].to_json())
{
  "account": "137.035999173",
  "circuits": [
    {
      "circuit_id": "acme-widgets-as-a-service",
      "impact": "NO-IMPACT"
    },
...
}

[glennmatthews]

Can this docstring please be detailed a bit more? Maybe with examples of what is meant by "notification data", how this can store one or several DataParts, etc.?

[chadell]

sure, this PR is not finished (documentation, tests, etc.). I will take this into account after the initial review of the design

[glennmatthews]

I think I suggested ProviderError in a previous review comment, but actually, should this be ProcessorError now?

[pke11y]

Perhaps I missed it, but is it documented what each element of _data_types represents?

[pke11y]

is it documented what each element of _data_types represents?

[chadell]

They are just arbitrary data types that you expect to match... so following your point, we could either document it or maybe create some ENUM that could help understanding them

[pke11y]

Makes sense. I'm sure documenting would suffice. No need to change type.

[glennmatthews]

Honestly it's a bit hard to follow with all the refactoring and reorganization of code but I think this appears reasonable. Let's get it merged so that we can start actually trying out some new parsers with the combined data.