Messaging Service Concept for Lucee.next

dev google-group-archive
1

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
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

2

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();
}

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

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

3

I think providing examples through an extension is definitely the way
forward here. Sounds interesting.On 23 February 2015 at 14:00, Christopher Dawes <@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.

…

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
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

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/1c9e11ef-9e4b-4a76-a695-bccd177bf692%40googlegroups.com
https://groups.google.com/d/msgid/lucee/1c9e11ef-9e4b-4a76-a695-bccd177bf692%40googlegroups.com?utm_medium=email&utm_source=footer
.
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: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn
http://www.linkedin.com/pixl8CONFIDENTIAL
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

4

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: Adam Cameron's Dev Blog: CFML: data connection objects instead of data sources

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.On Tuesday, 24 February 2015 03:00:10 UTC+13, Christopher Dawes wrote:

–
Adam

5

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

6

bump v6?