+1
On Wed, Nov 19, 2014 at 11:27 AM, Kasun Indrasiri wrote:
> Hi,
>
> At the moment 'Call' mediator offers a blocking messaging behavior on top
> of non-blocking architecture (i.e. - Request and responses are handled in
> different threads). However, there are requirements where we need to
> sup
Hi,
I think option 1 will be easier for users as they are far less likely to
forget an email address than a secret question (In addition to the answer
they will need to remember the question that they have selected) .
@Johann
> Any change this can be added as a gadget? That way we can reuse the
Hi,
At the moment 'Call' mediator offers a blocking messaging behavior on top
of non-blocking architecture (i.e. - Request and responses are handled in
different threads). However, there are requirements where we need to
support pure blocking messaging such as JMS transaction scenarios (which we
u
Hi All,
Please note that the method "*getTrainingOrganizers*" in the GoToTraining
connector will be renamed as "*listOrganizers*".
Thanks & Regards
Rasika
--
View this message in context:
http://wso2-oxygen-tank.10903.n7.nabble.com/Proposed-ESB-connector-scenario-Integrating-Canvas-LMS-with-E
Hi,
Better to have both, however prefer option 1 over 2
Touched, not typed. Erroneous words are a feature, not a typo.
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Hi Mifan
Thats a good suggestion but then the features will be hidden behind, and
the user will not have any idea what are the possible features we support
till he draws the polygons.
According to my understanding "crossing" does not make since for polygons
and it only works with lines and polyli
Hi Mifan,
Thank you for the suggestion, I will talk with the team about the new
approach.
Regards,
Damith.
On Tue, Nov 18, 2014 at 4:42 PM, Mifan Careem wrote:
> Hi Damith (resending to list)
>
> As discussed, I think a more generic approach which is scalable is as
> follows:
>
>
>- User c
Hi all,
Since we don't have any other ways to overcome this issue, I'm going with
the solution by implementing a method to remove the registry cache as
Shazni mentioned in the link. So before we doing a write call to the SM
registry we will call this method to clear the cache for the particular
pa
thanks a lot for the feedbacks..
On Tue, Nov 18, 2014 at 12:15 PM, Srinath Perera wrote:
> I also think Udara's idea is good.
>
> On Fri, Nov 14, 2014 at 11:49 PM, Udara Liyanage wrote:
>
>> Hi,
>>
>> So every time an app is accessed the incremented counter needs to be
>> written to db. Isn't i
Hi Damith (resending to list)
As discussed, I think a more generic approach which is scalable is as
follows:
- User creates an object. An object here is any spatial object (point,
line, polygon)
- User attaches a function or a set of functions to an object. Each
function would have i
This is already implemented by KasunG AFAIK.
Thanks,
Sameera.
On Tue, Nov 18, 2014 at 4:02 PM, Afkham Azeez wrote:
> +1. We must cleanup & call cleanup of all relevant deployers when the CApp
> deployer's cleanup method is called.
>
> On Tue, Nov 18, 2014 at 2:28 PM, Srinath Perera wrote:
>
>>
+1. We must cleanup & call cleanup of all relevant deployers when the CApp
deployer's cleanup method is called.
On Tue, Nov 18, 2014 at 2:28 PM, Srinath Perera wrote:
> We need to fix this? chat with Azeez
>
> On Wed, Oct 15, 2014 at 8:31 PM, KasunG Gajasinghe
> wrote:
>
>> Hi,
>>
>> I've been
Hi Shan,
Mobile context has hot topic for a long time. It comes in many forms.
1.
Device context - adopt the app to device
2.
Environment context - weather, noise, indoor or outdoor
3.
time context
4.
activity context - what is user trying to do?
5.
individual
Hi Pamod.
Thanks for bringing it up and I agree. To add to that, as suggested by
Srinath the ideal solution here would be to map MQTT QOS levels directly to
AMQP exchange types.
Given that, we could derive that QOS 0 is the exact non-durable topic
scenario running with consumers on auto_ack mode.
Hi Hasitha,
In the Andes Kernal level we need to have a mechanism to consider acks for
MQTT messages, for QOS 1 and 2 the acks will be considered and will be
retried if unacked. Specially in the case of QOS 1 type of messages.
Thanks,
Pamod
On Tue, Nov 18, 2014 at 3:16 PM, Hasitha Amal De Silva
Hi All,
Given our current messaging model, all messages go through a durable store,
and during non-durable topics, we use only one storage queue for multiple
consumers pointed at a single node for the same topic.
As discussed with HasithaH, This brings up the following concerns when
working with
Hi,
Up to now, Geo dashboard has following features.
Speed alert - generic
Proximity alert -generic
Within alert
Stationery alert
Above 'generic' means we have only one execution plan which will alter as
per the user's inputs. For each within or stationery alert a separate
execution plan will be
We need to fix this? chat with Azeez
On Wed, Oct 15, 2014 at 8:31 PM, KasunG Gajasinghe wrote:
> Hi,
>
> I've been testing the CAppDeployer functionality these days. One thing I
> noticed was that the cleanup operation in CappAxis2Deployer is an empty
> code block!
>
> Usually, the cleanup opera
Waruna, we do not know a data set yet, if there is one we would love to use
it.
One thought is taking KDD network activity dataset ( which is well known
benchmark for anomaly detection) and create a new dataset using that.
--Srinath
On Tue, Nov 18, 2014 at 1:48 PM, Seshika Fernando wrote:
>
Well the first usecase we are aiming for is Credit Card Fraud Detection at
Merchant level. We do not have readily available datasets (since these are
credit card transactions, usually this data is not readily available).
However, at this point we are only doing a POC to show that our system is
able
Hi Seshika,
Are you planning to test this based on some real world scenarios and data?
( ex: stock prices) Therefore to get and idea how accurate we can be.
Thanks,
On Tue, Nov 18, 2014 at 10:59 AM, Seshika Fernando wrote:
> Hi all,
>
> Following the implementation of Fraud Rules, and Markov C
21 matches
Mail list logo
