I can't for the life of me see how to attach an Entity Capabilities extension to a Smack Packet. In my case, I have the data ready to go, I just need to place it in the Packet class.
Am I missing something from the API? Can I add the <c/> element to a smack Packet?
There is an patch that adds Entity Capabilities support. The integration in Smack is tracked as SMACK-361 and the patch can be found in the forum post.
The patch is included in my smack fork (which get's used by aSmack). The <c/> element gets added in ServiceDiscoveryManager.java:258, with help of the CapsExtension. I am still working on the Entity Caps support in Smack in the caps branch and hope to get it committed some time in the future. You can view the current patch with git by using git diff upstream caps, after you have cloned the repository. If you have any suggestions, feel free to contact me.
Smack appears not to support this feature out of the box. You'll have to implement it yourself. Define a class that implements PacketExtension, create a new instance of this at the time of sending your presence and attach it using addExtension.
Related
I am getting started with OPCUA and eclipse milo and I am trying to understand how to best inform the client that a value or node has changed in the server.
So far my guess is that I need to trigger an event in the node that has changed, and then the client should monitor/subscribe to events in such node. Am I right on this?
If my understanding is correct, which event is most appropriated to trigger for this purpose?
I am using a free UI OPCUA client to test my server changes, and I need to refresh manually to observe my changes. I was expecting that by triggering the correct (OPCUA standard) event I would indicate the client to refresh automatically, is this possible?
Thanks!
You don't need Events to notify a client of an attribute change - that's the entire point of Subscriptions and MonitoredItems.
The client creates a MonitoredItem for the Value attribute (or any other attribute) and the server will report changes when that attribute changes.
As far as what you need to do as a user of the Milo Server SDK - see the ExampleNamespace. Your namespace implements the onDataItemCreated and other related methods to be notified that a client has created a MonitoredItem and you should start sampling values for it.
When using slack with GitHub, is there any option to send messages by checking labels. For example if in commit exists label "design", message will go to 'design' channel. Is there any ready implementation or we need to do something custom?
No, not yet (May 2018, a year after the OP's question)
This is still pending in integrations/slack issue 384
I'm a member of a Slack channel dedicated to a specific feature of a repo that covers a wide variety of features. Right now we have an internal Hubot to filter down to a specific label and then post messages to the channel.
It'd be cool if this official integration could replace our internal by allow subscribing to only issues/PRs that have a specific label instead of the entire repo.
So it is technically possible, but for now through the use of an external third-party bot.
There is PR for this feature, but has not yet been approved/merged (15 months after it was submitted)
https://github.com/integrations/slack/pull/797
Our team ended up creating a custom integration
When I append a new subscription in ORION, it automatically evaluates the condition and it invoques the designed end-point for that. I want that the new subscription affects only entities appended later.
Is there any way to avoid it or I have to control this at end-point level?
Related to this, is there any batch option to create several subscriptions at same time for a initial load of the platform?
Orion Version: 1.2.0
Regarding initial notification:
No, it isn't.
We understand that for some uses cases this is not convenient. However, behaving in the opossite way ruins another uses cases which need to know the "inicial state" before starting getting notifications corresponding to actual changes. The best solution to make everybody happy is to make this configurable, so each client can chose what it prefers. This feature is currently in our roadmap (see this issue in github.com).
While this gets implemented in Orion, in your case maybe a possible workaround is just ignore the first received nofitication belonging to a subscription (you can identify the subscription to which one notification belongs by the subscriptionId field in the notification payload). All the following notifications beloning to that subscription will correspond to actual changes.
Regarding batch option to create several subscriptions
No, there isn't any operation like that.
EDIT: the posibility of avoiding initial notification has been finally implemented at Orion. Details are at this section of the documentation. It is now in the master branch (so if you use fiware/orion:latest docker you will get it) and will be include in next Orion version (2.2.0).
My group is getting into web services for the first time. What is the usual way to control versioning issues with web services and clients? We're generating our services and clients using in IBM's RAD using the wizards it presents. The services and clients work well enough, but we're wondering how managing these will become a task going forward.
-If a service changes, and it's interface doesn't change I presume older clients would never know the difference and would work fine.
-If a service changes to add a new property to a parameter, would older clients work with it if they didn't need to set that value?
-How do people handle version control of web services as they grow in number and the number of apps using their clients grows? What is best practice on this sort of thing?
There are two types of versioning that we use. One that is visible to clients (public) and one that isn't (private). This comes from (what you already touched upon) whether clients are affected or not.
If clients are affect by, for example change in XSD Schema definitions or functionality of the WS changes in such way that clients must also modify their end, we change the public version. We increment the version number in WS context root, which means that it will have different URL than the previous version. Also make sure that the code archive, in our case they are war, have also the public version, as not to overwrite the previous deployment.
For example our WS called foo is in public version 2. Its URL is http://ourserver:8000/foo_2 and war file is called foo_2. We modified our XSD Schema, so the clients must react to the change. We update the version and now URL is http://ourserver:8000/foo_3 and war file is called foo_3. The previous version still exists, while clients can slowly transition to the new version.
If the change does not force any action from clients, then we call this private versioning. This usually shows up, in combination with public version, as a part of a project name. Using previous example, we have a WS foo, with private version 5 and public 2. Our project for this service is called WS_foo_2_5. We now change the order in which we store incoming data. This does not effect the clients, so we change the private version. In effect we have project WS_foo_2_6. We create a code archive from it called foo_2 and deploy it with URL set to http://ourserver:8000/foo_2. This way we modified the version, without changing anything from clients POV.
My team and I are working against a few webservices that require SOAP Message Headers to be available when making a request. We are not in control of these webservices so we can't change the implementation, even if we wanted to (or at least not without a lot of pain). We just need to be able to have authentication related information & a couple of other items passed through our message headers.
I've read of a few people who've had this problem in the past with no clear indication on if they succeeded in pulling it off on Monotouch.
Here's what I've read: http://forums.monotouch.net/yaf_postsm2104.aspx so far.
Any ideas on what we can do to overcome this on the Monotouch framework?
Here's what i'm trying to do for now:
using (var scope = new OperationContextScope (client.InnerChannel))
{
client.GetHistories += handler;
OperationContext.Current.OutgoingMessageHeaders.Add (MessageHeader.CreateHeader ("EnvironmentInfo", "http://schemas.contoso.com",
ServiceContext.Current.OperatingEnvironment));
OperationContext.Current.OutgoingMessageHeaders.Add (MessageHeader.CreateHeader ("AuthenticationToken", "http://schemas.contoso.com",
ServiceContext.Current.Token));
client.GetHistoriesAsync (ServiceContext.Current.OperatingEnvironment, ServiceContext.Current.Token, request);
}
Thanks for your time.
JM
I was not able to get Message Headers to work with WCF in Mono 2.6. I tried several different ways (including how you do it in your example) - it just doesn't work in Mono 2.6.
I raised a bug for this, which I then closed after discovering it is fixed in the latest trunk. So if you run against Mono 2.7 or greater, this should work.