Messaging Service Concept for Lucee.next

[Christopher Dawes]

I'll put this into a series of blog posts shortly, but wanted to post a dramatic idea, that would make most devs life a lot easier IMHO.

...

Over the years I've floated various ideas in the ColdFusion community around messaging and updating how CF engines interact.

I'd love to see a 'Messaging Service' (abstracted messaging functionality) in Lucee that allows for various types of messages to be sent (and extensions to add more) in a uniform way, not unlike how mappings allow different file systems to be abstracted.

It should be irrelevant 'how' it does it, (aka gateway, or direct functions/tags,etc)

---------------------

The idea is:

Work toward removing/hiding email settings page and move all kinds of messages to a central 'messagesource' (aka like datasource, but for messages).

Messaging connectors could be written, not unlike the way cache works also.

--

So in stage one we could have:

• Email
• Standard Mail Servers (smartermail, exchange, etc)
• API Based Services (mandrill, mailrocket, etc)
• SMS
• Individual Messages
• Mass Messaging (batch sending)
• Push Messages
• Individual Messages
• Mass Messaging (batch sending)
  
• Social
• Posting
• Reading Messages
• MessageBus (rabbitMq-like)
• Mailing Lists (eg: google groups)
• Post Messages
• Read Messages
• Custom Messaging API
• Roll your own extension to support your own random messaging system

this list is endless, however these are the main ones used all the time IMHO.

What is amounts to is a messaging set of functionality equivalent of a <cfmessage> tag or sendMessage() function which operates from a mailsource.

So you could have:

for email:
sendMessage(messagesource="mandrill2", subject="", message="", etc="");

for sms:

sendMessage(messagesource="clickatellftp" message="", recepients="");

Where the way a message is sent is abstracted away from the application in the same way mappings and datasources abstract away their respective complexity.

where you could sent an sms via clickatell via email to sms, ftp, smpp or other ways, but not have to care how that is done as it's a simple provider extension for messaging.

Likewise we could also roll the CFMAIL and CFIMAP into the same concept and abstract it to:

getMessages(messagesource="myimapserver", folder="Inbox") or getMessage(messagesource="clickatell2way") or getMessages(messagesource="facebook-work" or getMessages(type="twitter", user="@lucee", maxrows=10) 

---

I know it's a massive concept, but I'd love to see more abstractions like this so that the language moving forward is consistant.

Perhaps if people are interested I could start a railo extension that adds a series of tags to the language if there is enough support for the general concept and people around to help flesh out the 'standards' of an approach as this could also be used for other extensionsin the future (aka payment gateways (paypal,stripe,eway,etc), invoice solutions (xero,myob,etc) and so many others. Would be great to have a standard way to have extensions for extensions (something wordpress is sorting ATM also in their community)

Am I understanding the direction of Lucee (which is where I always wanted CF to go) to be heading in this direction?

This is a bit of a brain dump right now, but as I'm excited to what Lucee could be in v5... this is something that is a step further than just "cfmailsource" which I already have tickets in the system for, and a step further in the right direction (as pluggable functionality).

Getting started on this concept this week (rebuild from the ground up) anyway with v14 of my Diimes CFML framework, so either way I'll be heading in this direction, even if the community doesn't find this useful.

Thoughts, suggestions, criticism welcome. as a reply or privately back to my gmail.

Cheers,

Chris Dawes

[Jochem van Dieten]

On Mon, Feb 23, 2015 at 3:00 PM, Christopher Dawes wrote:

I'd love to see a 'Messaging Service' (abstracted messaging functionality) in Lucee

 

sendMessage(messagesource="mandrill2", subject="", message="", etc="");

 

Likewise we could also roll the CFMAIL and CFIMAP into the same concept and abstract it to:

getMessages(messagesource="myimapserver", folder="Inbox")

If you really want to abstract this, you should be able to just define a listener in your Application.cfc without having to define your own scheduler / poller. Something like:

this.messageSources=[

  {type="imap", server="", frequency="300", ...}

  , {type="JMS", server="", ...}

];

function onMessage(){

  getBean("messageService").processMessages();

}

Or perhaps:

function onJMSMessage(){

  getBean("messageService").processMessages();

}

function onIMAPMessage(){

  getBean("messageService").processMessages();

}

Jochem

--

Jochem van Dieten
http://jochem.vandieten.net/

[Dominic Watson]

I think providing examples through an extension is definitely the way forward here. Sounds interesting.

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/1c9e11ef-9e4b-4a76-a695-bccd177bf692%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Pixl8 Interactive, 3 Tun Yard, Peardon Street, London SW8 3HT, United Kingdom T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: in...@pixl8.co.uk

Follow us on: Facebook Twitter LinkedIn

CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB

[Adam Cameron]

On Tuesday, 24 February 2015 03:00:10 UTC+13, Christopher Dawes wrote:

I'll put this into a series of blog posts shortly, but wanted to post a dramatic idea, that would make most devs life a lot easier IMHO.

I think this is an excellent idea.

However not completely convinced by the implementation:

 

for email:
sendMessage(messagesource="mandrill2", subject="", message="", etc="");

 I have written what I think is the worst blog article I've spewed forth for some time, but I contextualise why I think this: http://blog.adamcameron.me/2015/03/cfml-data-connection-objects-instead-of.html

The TL;DR version is that I think a message source / message service should be an object not simply a label.

The general concept is a good 'un though.

-- 

Adam

[Christopher Dawes]

Remember also that each message type in this case would have a separate provider extension, which should be transparent for it's use, just as S3/file/Ram is transparent to a mapping, or 'mydatasource' could be any database type.

The core functionality types and the providers could be rolled and swapped out by anyone with your own store provider, or the core Lucee provider for extensions A new type 'provider' is an implementation. You should also be able to have for instance two providers of the same provider, but different implementation installed at once. (aka clickatell ftp provider (uses cfftp) and clickatell SMPP provider (uses gateway) ) where a first in best dressed naming convention applies.

---

So I'm thinking Lucee Extension for message, then provider plug-in providing the abstracted functionality allowing you to move from one to another without application reconfiguration.

so then with a payment extension in the same vein:

Senario : E-commerce payment:

Extension : Payment

Providers : Paypal, Cash, Xero

paypal and cash would be used to process the transaction payment, however xero could be used to generate an invoice for immediate OR delayed payment by cheque for instance.

Where all items have triggers or hooks into the implementation.

Demo and slides coming... I need to get my idea distilled... been in hospital on morphene for a week... #crazyhead

Chris