Date   

OpenMAMA-2.4.1 (hotfix release for deferred entitlements)

Frank Quinn <f.quinn@...>
 

Hi Folks,

 

We will be cutting a release shortly which is a hot fix release to include following change:

 

https://github.com/OpenMAMA/OpenMAMA/commit/daf1478b6ecc25b0dd453a56a826bc9b95dc7b18

 

Note that if you have fallen victim to this issue, you will not be able to subscribe to anything, so if you can subscribe to data sources and receive data today, you don’t need to upgrade.

 

Only users of middleware bridges which use deferred entitlements will require this change (i.e. Qpid, Avis, ZeroMQ and SR Labs bridges are unaffected).

 

I am aiming to get binaries available within the next day or two. Alternatively if you build your own, you can go ahead and build off the OpenMAMA-2.4.1 release branch.

 

Cheers,

Frank


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


Re: Gitter vs IRC

Frank Quinn <fquinn.ni@...>
 

Hi folks,

As we have heard no objections, we'll be going ahead with the move to gitter. It is ready to go right now and you'll find the usual IRC folks in Gitter. Meanwhile we'll work on updating all documentation etc to point to gitter rather than freenode.

Cheers,
Frank

On Tue, May 31, 2016 at 9:05 PM, Frank Quinn <fquinn.ni@...> wrote:
Hi folks,

We're currently looking at gitter as a potential IRC compatible replacement and my personal opinion is that we should go with it.

You can already mess about in the proposed channel; you can read anonymously, or use a github or twitter account to contribute: 

https://gitter.im/OpenMAMA/OpenMAMA

It has several great features:

1. Instant messages are persisted to the room, so you will see history when you log in
2. Sensible concurrent login access with no username1 nonsense
3. Web front end comes for free
4. Provided by github so integrates very nicely into the project wiki etc
5. Native client provided for Mac, windows, Linux, iPhone and android
6. Also compatible with standard IRC clients

Downsides:

1. It increases the github lock-in
2. You'll need a github or twitter account to contribute

If anyone has any feedback about making the move, please speak up now. I'm sending this to both users and developers because it will impact both and I'll welcome and consider all responses. I'd hope that we can agree a decision one way or another by 7th June, then (if necessary) take the plunge.

Cheers,
Frank


subscription is using destroyed publisher

Dmitri Fedorov <dfedorov.solace@...>
 

Hello gents, could you please confirm that the following looks like a MAMA layer issue, or maybe our bridge is not acting properly?
The issue: there is a subscription in process of activation or deactivation on one thread, and in that process it is trying to use a publisher that is in process of being destroyed or was already destoroyed in a different threat.
We would expect this publisher not being used (as it clearly has a state different from LIVE).
What do you think?
Thank you

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] PLAT-620: loading entitlements Libraries before payloads. (#185)
	mama/c_cpp/src/c/mama.c


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #79
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] MAMACPP: Keeping track of CPP wrappers to default queue (#174)
	mama/c_cpp/src/cpp/MamaQueue.cpp
	mama/c_cpp/src/cpp/mama/mamacpp.h
	mama/c_cpp/src/cpp/mamacpp.cpp


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #78
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] COMMON: Added support for format strings when evaluating properties
	common/c_cpp/src/c/property.h
	common/c_cpp/src/c/property.c


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #77
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Mama subscription state machine issue for subscription type basic and state ACTIVATING

cmorgan
 

Hi,

 

I’m currently having an issue when creating a basic type mamaSubscription. I’m trying to create the subscription with a wildcard to cause the bridge to return an invalid argument status and afterwards the state of the subscription is activating. Since the state is activating not activated I cannot deactivate, destroy, recreate(create again) or deallocate.  As a result I leak the memory associated with the subscription. The openmama C dev guide does not show a transition for the subscription state machine for the ACTIVATING state for basic subscriptions according to figure 1 page 32, from http://www.openmama.org/sites/default/files/OpenMAMA%20Developer's%20Guide%20C.pdf. What should be the expected behaviour for this error path?

 

Chris Morgan


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] Feature mamamsg vector price datetime (#163)
	mama/c_cpp/src/c/payload/qpidmsg/qpidpayloadfunctions.h
	mama/c_cpp/src/c/registerfunctions.c
	mama/c_cpp/src/gunittest/c/payload/payloadvectortests.cpp
	mama/c_cpp/src/c/payloadbridge.h
	mama/c_cpp/src/c/msg.c
	mama/c_cpp/src/gunittest/c/payload/fieldvectortests.cpp
	mama/c_cpp/src/c/mama/msg.h
	mama/c_cpp/src/gunittest/c/mamamsg/msgvectortests.cpp
	mama/c_cpp/src/c/payload/qpidmsg/payload.c
	mama/c_cpp/src/c/payload/qpidmsg/field.c
	mama/c_cpp/src/c/payload/qpidmsg/qpidcommon.h


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #76
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


advisory cause and platform info

Dmitri Fedorov <dfedorov.solace@...>
 

Hi,

What is an intended purpose of the advisory cause and platform info mechanizm in transport and subscription, please?

Thank you.

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.


Re: fields MdSubscMsgType and MdMsgType in message

Frank Quinn <fquinn.ni@...>
 

Well it might be depending on the value of the subsc type. See the dqpublisher code for more details.

On Wed, 1 Jun 2016, 18:41 Dmitri Fedorov, <dfedorov.solace@...> wrote:
The messages I'm talking about are published on _MDDD.<bridge>.DATA_DICT

So if a message 1) is coming on _MD.* and 2) its MamaFieldSubscMsgType is MAMA_SUBSC_* that is a subscription request, right?

Cheers,
Dmitri

On 1 June 2016 at 10:31, Frank Quinn <f.quinn@...> wrote:

Again, where are you seeing this message?

 

It sounds like your data source is publishing things that it shouldn’t. I can think of no good reason to publish MdSubscMsgType for anything other than a request of some kind. If you’re caching it, you shouldn’t because it will end up being specific to a single subscriber anyway.

 

The topic is also a big clue – subscription request come in on _MD.*

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: Wednesday, June 1, 2016 2:28 PM
To: Frank Quinn <fquinn.ni@...>
Cc: openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] fields MdSubscMsgType and MdMsgType in message

 

Hi Frank,

 

I see these messages in a dictionary publish case, when MdSubscMsgType is a dictionary entry (yes, I know it's a reserved word and shouldn't be used, this was not my idea to use it).

 

I can easily identify this message by its type (50), but I want to filter out other cases when this is NOT a subscription request message, but can legitimately have this MdSubscMsgType field.

 

BTW, what do you think is the best way to identify a subscription request (or non-subscription request message, if it's easier)? By presence of both fields MamaFieldSubscriptionType and MamaFieldSubscSymbol?

 

Thank you

Dmitri

 

On 1 June 2016 at 03:29, Frank Quinn <fquinn.ni@...> wrote:

Hi Dmitri,

Where are you seeing this message? This will be driven by the data source, but MdSubscMsgType is typically only included in subscription request messages (as suggested in the comment in subscmsgtype.h). I wouldn't expect it to provide any relevant information when sent in an update (in fact it probably shouldn't be included in updates).

Cheers,

Frank

 

On Tue, May 31, 2016 at 10:27 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:

Hi,

 

When a message has this field:

 MdSubscMsgType:61

 

and also it has this field:

 MdMsgType:1

 

am I right to assume that MdMsgType is the real message type?

 

In other words, does MdMsgType take precedence over MdSubscMsgType?

 

Do we have a legal/illegal combinations of MdMsgType and MdSubscMsgType?

 

Thank you.

 

Regards,

Dmitri Fedorov

Software Architect

Solace Systems, Inc.

Ottawa, ON Canada

 

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

 

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 

 


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


Re: fields MdSubscMsgType and MdMsgType in message

Dmitri Fedorov <dfedorov.solace@...>
 

The messages I'm talking about are published on _MDDD.<bridge>.DATA_DICT

So if a message 1) is coming on _MD.* and 2) its MamaFieldSubscMsgType is MAMA_SUBSC_* that is a subscription request, right?

Cheers,
Dmitri

On 1 June 2016 at 10:31, Frank Quinn <f.quinn@...> wrote:

Again, where are you seeing this message?

 

It sounds like your data source is publishing things that it shouldn’t. I can think of no good reason to publish MdSubscMsgType for anything other than a request of some kind. If you’re caching it, you shouldn’t because it will end up being specific to a single subscriber anyway.

 

The topic is also a big clue – subscription request come in on _MD.*

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: Wednesday, June 1, 2016 2:28 PM
To: Frank Quinn <fquinn.ni@...>
Cc: openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] fields MdSubscMsgType and MdMsgType in message

 

Hi Frank,

 

I see these messages in a dictionary publish case, when MdSubscMsgType is a dictionary entry (yes, I know it's a reserved word and shouldn't be used, this was not my idea to use it).

 

I can easily identify this message by its type (50), but I want to filter out other cases when this is NOT a subscription request message, but can legitimately have this MdSubscMsgType field.

 

BTW, what do you think is the best way to identify a subscription request (or non-subscription request message, if it's easier)? By presence of both fields MamaFieldSubscriptionType and MamaFieldSubscSymbol?

 

Thank you

Dmitri

 

On 1 June 2016 at 03:29, Frank Quinn <fquinn.ni@...> wrote:

Hi Dmitri,

Where are you seeing this message? This will be driven by the data source, but MdSubscMsgType is typically only included in subscription request messages (as suggested in the comment in subscmsgtype.h). I wouldn't expect it to provide any relevant information when sent in an update (in fact it probably shouldn't be included in updates).

Cheers,

Frank

 

On Tue, May 31, 2016 at 10:27 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:

Hi,

 

When a message has this field:

 MdSubscMsgType:61

 

and also it has this field:

 MdMsgType:1

 

am I right to assume that MdMsgType is the real message type?

 

In other words, does MdMsgType take precedence over MdSubscMsgType?

 

Do we have a legal/illegal combinations of MdMsgType and MdSubscMsgType?

 

Thank you.

 

Regards,

Dmitri Fedorov

Software Architect

Solace Systems, Inc.

Ottawa, ON Canada

 

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

 

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 

 


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


Re: fields MdSubscMsgType and MdMsgType in message

Frank Quinn <f.quinn@...>
 

Again, where are you seeing this message?

 

It sounds like your data source is publishing things that it shouldn’t. I can think of no good reason to publish MdSubscMsgType for anything other than a request of some kind. If you’re caching it, you shouldn’t because it will end up being specific to a single subscriber anyway.

 

The topic is also a big clue – subscription request come in on _MD.*

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: Wednesday, June 1, 2016 2:28 PM
To: Frank Quinn <fquinn.ni@...>
Cc: openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] fields MdSubscMsgType and MdMsgType in message

 

Hi Frank,

 

I see these messages in a dictionary publish case, when MdSubscMsgType is a dictionary entry (yes, I know it's a reserved word and shouldn't be used, this was not my idea to use it).

 

I can easily identify this message by its type (50), but I want to filter out other cases when this is NOT a subscription request message, but can legitimately have this MdSubscMsgType field.

 

BTW, what do you think is the best way to identify a subscription request (or non-subscription request message, if it's easier)? By presence of both fields MamaFieldSubscriptionType and MamaFieldSubscSymbol?

 

Thank you

Dmitri

 

On 1 June 2016 at 03:29, Frank Quinn <fquinn.ni@...> wrote:

Hi Dmitri,

Where are you seeing this message? This will be driven by the data source, but MdSubscMsgType is typically only included in subscription request messages (as suggested in the comment in subscmsgtype.h). I wouldn't expect it to provide any relevant information when sent in an update (in fact it probably shouldn't be included in updates).

Cheers,

Frank

 

On Tue, May 31, 2016 at 10:27 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:

Hi,

 

When a message has this field:

 MdSubscMsgType:61

 

and also it has this field:

 MdMsgType:1

 

am I right to assume that MdMsgType is the real message type?

 

In other words, does MdMsgType take precedence over MdSubscMsgType?

 

Do we have a legal/illegal combinations of MdMsgType and MdSubscMsgType?

 

Thank you.

 

Regards,

Dmitri Fedorov

Software Architect

Solace Systems, Inc.

Ottawa, ON Canada

 

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

 

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 

 


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


Re: fields MdSubscMsgType and MdMsgType in message

Dmitri Fedorov <dfedorov.solace@...>
 

Hi Frank,

I see these messages in a dictionary publish case, when MdSubscMsgType is a dictionary entry (yes, I know it's a reserved word and shouldn't be used, this was not my idea to use it).

I can easily identify this message by its type (50), but I want to filter out other cases when this is NOT a subscription request message, but can legitimately have this MdSubscMsgType field.

BTW, what do you think is the best way to identify a subscription request (or non-subscription request message, if it's easier)? By presence of both fields MamaFieldSubscriptionType and MamaFieldSubscSymbol?

Thank you
Dmitri

On 1 June 2016 at 03:29, Frank Quinn <fquinn.ni@...> wrote:
Hi Dmitri,

Where are you seeing this message? This will be driven by the data source, but MdSubscMsgType is typically only included in subscription request messages (as suggested in the comment in subscmsgtype.h). I wouldn't expect it to provide any relevant information when sent in an update (in fact it probably shouldn't be included in updates).

Cheers,
Frank

On Tue, May 31, 2016 at 10:27 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:
Hi,

When a message has this field:
 MdSubscMsgType:61

and also it has this field:
 MdMsgType:1

am I right to assume that MdMsgType is the real message type?

In other words, does MdMsgType take precedence over MdSubscMsgType?

Do we have a legal/illegal combinations of MdMsgType and MdSubscMsgType?

Thank you.

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev




Re: Code change(s) just landed on origin/next (Successful)

Frank Quinn <f.quinn@...>
 

Hi Folks,

 

Please ignore these no changes notifications– this was just testing Jenkins integration with gitter (which is now working).

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of jenkins@...
Sent: Wednesday, June 1, 2016 12:03 PM
To: openmama-dev@...
Subject: [Openmama-dev] Code change(s) just landed on origin/next (Successful)

 

Some changes have just been added to the origin/next branch!

 
No changes
 

Results for OpenMAMA Next Branch (Qpid Proton) CI run with latest changes:

 

  • CI Project Name: OpenMAMA Next Branch (Qpid Proton)
  • Build Number: #64
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

No changes

Results for OpenMAMA Next Branch (Qpid Proton) CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch (Qpid Proton)
  • Build Number: #64
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

No changes

Results for OpenMAMA Next Branch (Qpid Proton) CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch (Qpid Proton)
  • Build Number: #63
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Re: subscribers notification to publishers

Frank Quinn <f.quinn@...>
 

Hi Dmitri,

 

Check out section 13.2 in this: http://www.openmama.org/sites/default/files/OpenMAMA%20Developer's%20Guide%20C.pdf and also table 12.

 

Also check out dqpublishermanager.h and capturereplay example apps for working examples.

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: Tuesday, May 31, 2016 10:43 PM
To: openmama-dev <openmama-dev@...>
Subject: [Openmama-dev] subscribers notification to publishers

 

Could you please point me in the code where I would be able to see what notifications and under what conditions are generated by OpenMAMA from subscribers to publishers?

 

Thank you in advance.

 

Regards,

Dmitri Fedorov

Software Architect

Solace Systems, Inc.

Ottawa, ON Canada

 

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


Re: fields MdSubscMsgType and MdMsgType in message

Frank Quinn <fquinn.ni@...>
 

Hi Dmitri,

Where are you seeing this message? This will be driven by the data source, but MdSubscMsgType is typically only included in subscription request messages (as suggested in the comment in subscmsgtype.h). I wouldn't expect it to provide any relevant information when sent in an update (in fact it probably shouldn't be included in updates).

Cheers,
Frank

On Tue, May 31, 2016 at 10:27 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:
Hi,

When a message has this field:
 MdSubscMsgType:61

and also it has this field:
 MdMsgType:1

am I right to assume that MdMsgType is the real message type?

In other words, does MdMsgType take precedence over MdSubscMsgType?

Do we have a legal/illegal combinations of MdMsgType and MdSubscMsgType?

Thank you.

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev



Re: Gitter vs IRC

Damian Maguire <d.maguire@...>
 

Having toyed with it a bit, as well as many of the alternatives, I think Gitter is a really good option – public, easy to use for new users (beats IRC on that front), enough platform support for regular users to work with, preserves history (again beats IRC default), much more open than Slack etc. Integrations might need some work (CI notifications in the IRC channel are nice for example), but I think we can work around that.

 

So yeah, my vote is go for it (with some sort of plan for deprecating Freenode of course).

 

Cheers,

 

D

 

Damian Maguire

Senior Sales Engineer

Desk (Direct): +4428 9568 0298

 

From: <openmama-dev-bounces@...> on behalf of Frank Quinn <fquinn.ni@...>
Date: Tuesday, May 31, 2016 at 9:05 PM
To: openmama-dev <openmama-dev@...>, "openmama-users@..." <openmama-users@...>
Subject: [Openmama-dev] Gitter vs IRC

 

Hi folks,

We're currently looking at gitter as a potential IRC compatible replacement and my personal opinion is that we should go with it.

 

You can already mess about in the proposed channel; you can read anonymously, or use a github or twitter account to contribute: 

 

https://gitter.im/OpenMAMA/OpenMAMA

It has several great features:

1. Instant messages are persisted to the room, so you will see history when you log in
2. Sensible concurrent login access with no username1 nonsense
3. Web front end comes for free
4. Provided by github so integrates very nicely into the project wiki etc
5. Native client provided for Mac, windows, Linux, iPhone and android
6. Also compatible with standard IRC clients

Downsides:

1. It increases the github lock-in
2. You'll need a github or twitter account to contribute

If anyone has any feedback about making the move, please speak up now. I'm sending this to both users and developers because it will impact both and I'll welcome and consider all responses. I'd hope that we can agree a decision one way or another by 7th June, then (if necessary) take the plunge.

Cheers,
Frank


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


subscribers notification to publishers

Dmitri Fedorov <dfedorov.solace@...>
 

Could you please point me in the code where I would be able to see what notifications and under what conditions are generated by OpenMAMA from subscribers to publishers?

Thank you in advance.

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

541 - 560 of 2305