Message Lib instead of Mail only ?

Hi, 

I wan't to open one thread about the Mail system in CI 4. 
Those days sending message / notification is possible not only by e-mail but and by many other gateways "SMS, 3rd party apps (FB, Google, etc..)"

Wouldn't it be better if in CI 4 instead of Mail library there is Message library with email as the only base supported gateway ? 
This way anyone will be able to add any kind of message gateways and to use it by standard framework class/methods following just a base driver interfaces..

In most of the cases a Message (mail or other) has very common things : Sender, Receiver, Message, Attachment.. 
Of course there will be some differences as some of the gateways will require to be authenticated (maybe some key or other) but this will be handled by the drivers and not by the base Message class..

Best VPS Hosting : Digital Ocean

Can you see the problems with this when Facebook, Twitter or Google updates their API's?

What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )

Can you see the problems with this when Facebook, Twitter or Google updates their API's?

As I said Message lib with e-mail supported "gateway" by CI4 in default.
All 3rd parties code should be out of the ci 4 source . 

But in your code it would be a lot easier if you got..

$mailMessanger (instance of Messanger Mail) ->sendMessage($from, $to, $message...); .. 
$fbMessanger( instance of 3rd party Messanger) ->sendMessage($to, $message .. - $from should be the app user or what ever is implement)

At the end Mail, FB notification, message and etc.. all of those things are messages From(user/app) To(user/app)..

P.S. Such message system can be used at the same time for external and internal messages depending on which "driver" its using and how its configured..
(if you need to send either internal message or/and an email to some client) ..

Best VPS Hosting : Digital Ocean

Hmm - is this along the lines of http://forum.codeigniter.com/thread-64551.html ?
Would this be addressed by https://github.com/bcit-ci/CodeIgniter4/issues/117 or https://github.com/bcit-ci/CodeIgniter4/issues/276 ?

Hmm - is this along the lines of http://forum.codeigniter.com/thread-64551.html ?
Would this be addressed by https://github.com/bcit-ci/CodeIgniter4/issues/117 or https://github.com/bcit-ci/CodeIgniter4/issues/276 ?

Its not a Queue for sure..
I was watching #276 the Email library and I thought that instead of class as Email/Message we should have in fact Message with "type" email ..

Mails, Sms or FB message, those all are Messages. Just that the email is some old standard for web message which is easiest to be supported. 
Usually in any case there are: Sender (me) , Receiver .. Message ..

Best VPS Hosting : Digital Ocean

Both can exist ... if there's a generic messaging library, it could have an email adapter built on top of Email\Message.

Both can exist ... if there's a generic messaging library, it could have an email adapter built on top of Email\Message.

Its an option yes.
 
Those days almost all sites built have integration of some  3rd party application with messaging/notifications or SMS verification and etc. (all the time sending some messages to somebody out of the site)..

I think that replacing the email with messenger with email "adapter" and providing the interfaces to build other type of messenger adapters is a good idea for this new major CI version . Emails performance won't be worse if it follows such structure, just instead of loading an email lib it will be a messenger factory > email.

Best VPS Hosting : Digital Ocean

Both can exist ... if there's a generic messaging library, it could have an email adapter built on top of Email\Message.

Its an option yes.
 
Those days almost all sites built have integration of some  3rd party application with messaging/notifications or SMS verification and etc. (all the time sending some messages to somebody out of the site)..

I think that replacing the email with messenger with email "adapter" and providing the interfaces to build other type of messenger adapters is a good idea for this new major CI version . Emails performance won't be worse if it follows such structure, just instead of loading an email lib it will be a messenger factory > email.

You don't quite get what I'm saying - replacing is pointless. It will solve your problem, but will make others unhappy.
If I only want email, I don't want needless abstractions forced upon me.

CI\Email must remain stand-alone. The point of adapters is to act as mediators, not concrete implementations.

You don't quite get what I'm saying - replacing is pointless. It will solve your problem, but will make others unhappy.
If I only want email, I don't want needless abstractions forced upon me.

CI\Email must remain stand-alone. The point of adapters is to act as mediators, not concrete implementations.

I understood you right the first time. 

My suggestion is based on the current trends at the web apps. 
In the past "Send Message to user" meant in almost 100% of the cases - send Email. But today its not the same. 
Its most likely that there will be 1 small "needless abstractions" but I don't think that it will be so big deal to blacklist the idea.
Sending an email is usually not so fast process, and some abstraction won't deal much delay..

The benefit will be big for those who are sending messages not only as emails (and this group is not small and its growing) .
It will be 1-2 lines of code for sending messages to any kind of 3rd party app (Gmail as mail, FB as notification,some GSM as SMS) 

I think that we should think out of the box, not only about the most regular and simplest case.

You don't quite get what I'm saying - replacing is pointless. It will solve your problem, but will make others unhappy.
If I only want email, I don't want needless abstractions forced upon me.

CI\Email must remain stand-alone. The point of adapters is to act as mediators, not concrete implementations.

I understood you right the first time. 

My suggestion is based on the current trends at the web apps. 
In the past "Send Message to user" meant in almost 100% of the cases - send Email. But today its not the same. 
Its most likely that there will be 1 small "needless abstractions" but I don't think that it will be so big deal to blacklist the idea.

I'm not blacklisting the idea, but the way you think it should be implemented.

By saying "replace", it is implied that:

- There's no longer a stand-alone email library
- You can only send emails through the said Messenger library
- If you want to use a different email library implementation, the existing example would encourage you to write a completely new "driver"

It's not only a needless abstraction for those that don't want it, but these three conditions are also inherent limitations. All for the sake of following a current trend.

If instead you have Messenger\EmailAdapter forwarding calls to Email\Message, you can do both, with no limitations and this is in fact more abstract.

Sending an email is usually not so fast process, and some abstraction won't deal much delay..

Delays aren't the concern.

The benefit will be big for those who are sending messages not only as emails (and this group is not small and its growing) .
It will be 1-2 lines of code for sending messages to any kind of 3rd party app (Gmail as mail, FB as notification,some GSM as SMS) 

I think that we should think out of the box, not only about the most regular and simplest case.

Well, that's the thing - you have a good idea, but you want to shoehorn it into the same single-simplest-case approach, just redefining what the scope of "single simplest" is.
In other words, you've had a thought while you were outside the box, but then jumped into that very box before pondering it.