Opened 10 years ago

Last modified 10 years ago

#22 new task

Specifying BearMail::Backend

Reported by: Vincent Caron Owned by: Vincent Caron
Priority: minor Component: Bearmail
Keywords: Cc: Benjamin Linet, Valentin SCHMITT

Description

Current BearMail::Backend has no API, it simply picks the only available backend (source:/bearmail/lib/BearMail/Backend/Files.pm). There is no separation between usage and storage and this is bad:

  • The API cannot be implemented efficiently, for instance one cannot load 'all domains' if the backend is a SQL table with 100,000 tuples.
  • The autorization framework is mixed with storage issues, it should stand on its own

The idea is to properly design BearMail::Backend which is actually Bearmail's core - the object you must create before doing anything useful - with those remarks in mind.

Change History (5)

comment:1 Changed 10 years ago by Vincent Caron

To program this framework properly, it is very useful to have one module per notion. Even if the module only stores a string and is more or less equivalent to a simple $scalar. We lack those:

  • BearMail::Address : an email address, something than can be decomposed (name <left@right>), parsed, checked, etc. It may rely on tons of available modules like Mail::RFC822::Address.
  • BearMail::Domain : many informations and decisions are domain-based, this should be useful
  • BearMail::Target: describes where an email can be routed (maildir, other emails, program, etc)
  • BearMail::Account: an object which describes a (address, auth, target) triple like we are used to manipulate in "mailmap". I don't know if we need a BearMail::Auth module at this point, we'll see.

The backend should let us:

  • retrieve domain(s) or account(s) on useful criteria (exact matching, simple wildcard, paging)
  • retrieve stats
  • create, modify and delete a domain
  • create, modify and delete an account
  • optionnaly append and retrieve an event log

... while obviously checking autorizations. Which means we're lacking a context about the "current user". It only exists in the we part right now... So let's add to the backend:

  • a login method and a current_user notion

comment:2 Changed 10 years ago by zerodeux

(In [571]) Bootstrapped dummy BearMail::{Address,Target,Domain,Account} modules, see #22

comment:3 Changed 10 years ago by zerodeux

(In [574]) Starting BearMail::Backend spec (at least), POD and new() bootstrapped - see #22

comment:4 Changed 10 years ago by zerodeux

(In [576]) BearMail::Backend firt draft: autorization part is not documented, and thus some API might be lacking - see #22

comment:5 Changed 10 years ago by zerodeux

(In [577]) Documented most BearMail::Backend API, had to change a few things in BearMail::Config - see #21 and see #22

Note: See TracTickets for help on using tickets.