Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [4diac-dev] Reworking Deployment/Download


I think the merge is not a good idea. I think user wouldn't know what the "merge" actually does. Regarding the persistent deployment of application, here's a bug:

I think the tool should basically manage the forte.fboot file (write one for deploying/overwrite (this could be checked before doing it), delete it for cleaning, etc.). 
I also think that 4diac should start using the 61499 XML file for the loading of the applications/resources, instead of the current forte.fboot commands. 4diac-ide should be able to export the device contents of each device in separate files, and 4diac-rte should be able to read them. This way, it would be more tool independent. 

Another idea, not sure if it's a step back, is to have applications (or maybe devices) in separate files, in order to have a better distributed contribution to a system. We had the case when with some colleagues we started implementing a system with many devices and applications. We assigned one application to each developer, but using git wasn't so helpful since all the changes were done on the same file, bringing conflicts with every commit. 

Jose Cabral

Forschungsinstitut des Freistaats Bayern für
softwareintensive Systeme und Services
Guerickestraße 25 
80805 München
Tel.: +49 (89) 3603522 529
Fax: +49 (89) 3603522 50 
E-Mail: cabral@xxxxxxxxxxx

Amtsgericht München: HRB: 176633
USt-IdNr.: DE263907002, Steuer-Nr.: 143/237/25900
Rechtsform: gemeinnützige GmbH
Sitz der Gesellschaft: München
Geschäftsführer: Dr. Harald Rueß, Thomas Vallon
Vorsitzender des Aufsichtsrats: Dr. Manfred Wolter

-----Ursprüngliche Nachricht-----
Von: 4diac-dev-bounces@xxxxxxxxxxx <4diac-dev-bounces@xxxxxxxxxxx> Im Auftrag von Michael Golz
Gesendet: Samstag, 28. April 2018 15:23
An: alois.zoitl@xxxxxx; 4diac developer discussions <4diac-dev@xxxxxxxxxxx>
Betreff: Re: [4diac-dev] Reworking Deployment/Download

Hi Alois,

I would delete on override the RES and then load the new (same name).
Without versioning like Git or filedump you can never match them.
But the problem will be the re-drawing on the runtime to compare something.
I do not know how to do that with the current state.

My idea would be an xml image on the runtime and this will be reloaded after a finished command (like the fboot), this XML Dump can maybe  merged, but not quite thought out would have considered how to manage the memory.

Von meinem iPhone gesendet

> Am 27.04.2018 um 21:12 schrieb Alois Zoitl <alois.zoitl@xxxxxx>:
> Hi Michael,
>> On Thu, 2018-04-26 at 17:44 +0200, Michael Golz wrote:
>> Hi Alois,
>> i think override/override all and cancel/cancel all will be enough.
>> It may sound good to merge but there can be a lot goes wrong.
> I was not so sure about the override all. Wouldn't it be dangerouse as 
> I may not remember what resources/devices will be downloaded and then 
> I may kill something I don't want (e.g., running machine). Should 
> there be a second dialog with a list of all resources to be downloaded 
> for configuration on override all?
>> I would like to have a function to create and write the fboot in the 
>> runtime back to the file system, then i can remove my own upload 
>> tool.
> Sound like a conveniant feature. Even if I don't know how to implement 
> it :-) Could you be so kind and create an issue for that in our 
> bugzilla so that we don't loos it.
>> Thanks for the great work!
> Thanks.
>> Sunny greetings from Egypt
>> Michael
> Enjoy the sun,
> Alois
>> Von meinem iPhone gesendet
>>> Am 26.04.2018 um 10:38 schrieb Alois Zoitl <alois.zoitl@xxxxxx>:
>>> Now with the 1.9.0 release finished I think its time to look ahead 
>>> and start pondering about what we would like to have in 1.10.
>>> One part we haven’t spent to much work on in recent releases is the 
>>> download process and the deployment console. There I several issues 
>>> that should be fixed.  With this thread I would like to start the 
>>> discussion and planing for potential improvements here.
>>> One thing that I think would make 4diac much easier to use if we 
>>> would better handle downloading the same resource several times 
>>> (i.e., the infamous “Invalid State”error).
>>> I was thinking that the on the beginning of a download the devices 
>>> should be queried on the currently running resources and if the 
>>> resource to deploy the user should be asked how to proceed. For such 
>>> a dialog I drafted a first mock up with different actions for such a 
>>> dialog.
>>> My questions on it are:
>>>   • Is this the right approach?
>>>   • Is there information missing in the dialog's text.
>>>   • Is it clear that “overwrite” means that the currently running 
>>> resource will be deleted and the current config will be downloaded
>>>   • Is a merge feasible, or would it lead to very complicated even 
>>> dangerous situations?
>>>   • Is a cancle and a cancle all needed or only one of both?
>>> In addition to this I also heard from several users that the switch 
>>> to the deployment console is very cumbersome and disturbs the 
>>> development flow. Therefore getting rid of it and integrating it 
>>> into the system perspective could also be a goal. Here I don’t have 
>>> not really an idea how to do this.
>>> Looking forward to your ideas and comments, Alois 
>>> <ResourceQuestionMockUp.png> 
>>> _______________________________________________
>>> 4diac-dev mailing list
>>> 4diac-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or 
>>> unsubscribe from this list, visit 
> _______________________________________________
> 4diac-dev mailing list
> 4diac-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit 

4diac-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top