asterics
Bump y18n from 4.0.0 to 4.0.1
Bumps y18n from 4.0.0 to 4.0.1.
Changelog
Sourced from y18n's changelog.
Change Log
All notable changes to this project will be documented in this file. See standard-version for commit guidelines.
5.0.5 (2020-10-25)
Bug Fixes
5.0.4 (2020-10-16)
Bug Fixes
5.0.3 (2020-10-16)
Bug Fixes
5.0.2 (2020-10-01)
Bug Fixes
5.0.1 (2020-09-05)
Bug Fixes
5.0.0 (2020-09-05)
⚠ BREAKING CHANGES
- exports maps are now used, which modifies import behavior.
- drops Node 6 and 4. begin following Node.js LTS schedule (#89)
Features
... (truncated)
Commits
- See full diff in compare view
Maintainer changes
This version was pushed to npm by oss-bot, a new releaser for y18n since your current version.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
-
@dependabot rebasewill rebase this PR -
@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it -
@dependabot mergewill merge this PR after your CI passes on it -
@dependabot squash and mergewill squash and merge this PR after your CI passes on it -
@dependabot cancel mergewill cancel a previously requested merge and block automerging -
@dependabot reopenwill reopen this PR if it is closed -
@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually -
@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) -
@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) -
@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -
@dependabot use these labelswill set the current labels as the default for future PRs for this repo and language -
@dependabot use these reviewerswill set the current reviewers as the default for future PRs for this repo and language -
@dependabot use these assigneeswill set the current assignees as the default for future PRs for this repo and language -
@dependabot use this milestonewill set the current milestone as the default for future PRs for this repo and language
You can disable automated security fix PRs for this repo from the Security Alerts page.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "Published by a pub.dev verified publisher"){kind=small}
Unfortunately the naming of IComponentType, IComponentInstance and IRuntimeComponentInstance is very confusing, I think. IMHO there should be 2 levels: IComponentType: describing the metadata, type of a component/plugin IRuntimeComponentInstance: real instance of a given IComponentType
The question is, if the ASAPI method getComponentProperty should refer to the component type properties or the runtime property values. I interpreted it as runtime property values and I think that's what is actually needed. DeploymentManager.instance.getComponentProperty returns the runtime property values by calling the method IRuntimeComponentInstance.getRuntimePropertyValue (which is actually the best name I think). About the solution: I think get|setRuntimePropertyValue would be a good name. I don't think that ASAPI has to provide the metalevel of the properties directly, because if somebody is interested he/she can fetch the bundle descriptors with getComponentDescriptorsAsXml().
Cheers
Am 09.06.2016 um 17:20 schrieb mariokom:
*The need*Implement a web client that is able to monitor specific AsTeRICS components. These components are periodically change some of their property values
*The problem*The changes are not visible from any external (neither ASAPI nor REST) client.
*The cause*ASAPI's getComponentProperty uses this:
DeploymentManager.instance.getCurrentRuntimeModel().getComponentProperty(componentID, key);The line above is accessing property variables created by Deployment manager and not the component's property variables (unfortunately there are two seperate instances for the same property).
On the other hand this line:
DeploymentManager.instance.getComponentProperty(componentID, key);is directly accessing the components property variables ( prop* ). ASAPI does not currently provide this kind of functionality.
*The solution*Introduce two new ASAPI functions able to handle actual component property variables and expose them through REST api ( getExplicitComponentProperty, setExplicitComponentProperty ??? )
Comments? objections?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/asterics/AsTeRICS/issues/123, or mute the thread https://github.com/notifications/unsubscribe/AEaF8t52KpvPPMaCYhxSRU2FHIoT4SGKks5qKC9QgaJpZM4IyF1f.
Martin Deinhofer, MSc Research and Development, International Projects
University of Applied Sciences Technikum Wien Hoechstaedtplatz 6, 1200 Vienna, Austria, Europe T: +43 1 333 40 77-297, F: +43 1 333 40 77-99 297 E: [email protected] I: embsys.technikum-wien.at
I agree that the ASAPI's set|getComponentProperty are unecessary.
I will add the new functions with the names you 've proposed. With this addition - and if a plugin is implemented properly - an external client can monitor Asterics on a component level, which is something that was missing before from the API.
for example: in a MidiPlayer component, each time a note is played, write its information on property variables. A client then can monitor the property values and reproduce the same melody.
Thank you Martin for your comments
Hi Marios,
Please wait a second, when thinking more about the topic I think there are some misunderstandings.
Actually, the stated problem is not existent, because if open the C#-ACS, connect to the ARE and change the property of a plugin it's is changed in the runtime property instance. So actually it works, it's just the name that is not very intuitive. Secondly, the methods get/setPortProperty and get/setChannelProperty do the same for the respective category (port properties and channel properties). So if you change the names, please change it for all of them. As time is close to the next release, I think we should postpone this API incompatible step to the last phase of P4All. Additionally, let's discuss how to fully support the synchronization/data flow of property values, event listening/triggering and port data propagation between the ARE and multiple clients.
As I understand we currently have: *) REST API to set | get runtime property values *) SSE mechanism for model lifecycle events and a REST API for publish/subscribe to such events *) websocket plugin that can forward and receive connected port data between the ARE and webclients
What's still missing: *) forward / receive plugin events (through SSE?) *) Support multiple clients: If one client or the ARE gui changes a value of a property, also notify all listeners by pushing the change (otherwise they would have to poll all the time). *) forward / receive selected port data (through websocket) *) Maybe some of the features should be possible for both REST/SSE and websocket interfaces...
What do you think? Martin
Am 10.06.2016 um 15:56 schrieb mariokom:
I agree that the ASAPI's set|getComponentProperty are unecessary.
I will add the new functions with the names you 've proposed. With this addition - and if a plugin is implemented properly - an external client can monitor Asterics on a component level, which is something that was missing before from the API.
for example: in a MidiPlayer component, each time a note is played, write its information on property variables. A client then can monitor the property values and reproduce the same melody.
Thank you Martin for your comments
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/asterics/AsTeRICS/issues/123#issuecomment-225188628, or mute the thread https://github.com/notifications/unsubscribe/AEaF8twKnWIXgc8Lv7XSY-O1anvJg82zks5qKW0TgaJpZM4IyF1f.
Martin Deinhofer, MSc Research and Development, International Projects
University of Applied Sciences Technikum Wien Hoechstaedtplatz 6, 1200 Vienna, Austria, Europe T: +43 1 333 40 77-297, F: +43 1 333 40 77-99 297 E: [email protected] I: embsys.technikum-wien.at
Hi Martin,
Sorry in advance if the following response is too technical :)
Actually, this is not what i wanted to achieve. My scenario is to change the variable from the component itself and the change to be visible from the external client. Why is the ACS able to achieve this? It changes both variable properties (AsapiSupport - line 1133, 1138) every time a client calls the setPropertyValue, but the getPropertyValue function reads what has been written by the line 1133 (which in this case there is no difference). Now, if a component changes its own variable (equivalent to the line 1138), it will not be visible by an external client. We could use the line 1133 in the component's setRuntimePropertyValue (to change both variables), but in my opinion this is a very bad practice since it creates a direct dependency from the component to the middleware. Additionally, i was not able to identify a similar behevior with the get/setPortProperty and get/setChannelProperty cases. With the above in mind, Is there something i did not understand?
All of the 'still missing' points are very good. The 'complication' is that the solution(s) - as i imagine it - needs DeploymentManager refactoring. I think at some point we should discuss these futher (may be on a skype meeting?).
Marios
Forgot to mention that the changes are part of a P4All deliverable which must be submitted before the 10nth of July. Do we plan the next release before or after this date?
Hi Marios,
I think the mistake in the current implementation is that the IRuntimeModel instance is also updated with property changes, but this is IMHO not necessary. The IRuntimeModel instance only describes the initial configuration of components (initial property values,...) and the interconnections of components by data ports and event channels.
The IRuntimeComponentInstance should be the only place to hold the current states of a component. We could use the abstract class AbstractRuntimeComponentInstance#setRuntimePropertyValue to add generic functionality like change listener notification. Unfortunately this will only work, if all the plugins use super.setRuntimePropertyValue in their implementations.
Having a skype call is a good idea. The release must definitely be before July 10th, preferably one week before, because we also need it for our Summer School. Do you mean that the multiple client synchronization must be implemented for this release (2.8) already? This sounds very tough!! :-)
Cheers Martin
Ok lets move this conversation on skype. No i was not planning to implement it for 2.8 (i can sense a small panic attack just by mentioning it :p ). I was asking just to figure out if i needed to maintain a different version of AsTeRICS just for the deliverable. Since the release will be taking place before, i think we are fine.