Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [viatra-dev] VIATRA Transformation API - Adapter based extension framework

Hi,

I don’t really see how this aspect overlaps with the Hierarchic EVM concept, as we are augmenting a single EVM to have some additional functionality available.

About EVM/VIATRA, this is a good point; the original concept was to augment the VIATRA API only, but indeed, some of the ideas rely on changing the lower level components, such as conflict resolvers, as well. We should indeed split up (for the sake of simplicity at first at the package level, then moving the EVM-based stuff to IncQuery at a later point).

Cheers,
Zoli
-- Zoltán Ujhelyi

Technology Expert
IncQueryLabs Ltd.

> On 24 Sep 2015, at 12:02, István Ráth <rath@xxxxxxxxxx> wrote:
> 
> Hi,
> 
> I have one major comment: at first glance, this work seems to be very much overlapping with the “Hierarchic EVM” concept that we discussed a while back, as one of the future development directions to achieve a tighter integration between various EVM-based executors such as VIATRA batch/live, CEP and DSE.
> 
> In fact, one of the confusing aspects of the wiki page is that it talks about “VIATRA Adapters”, whereas, at least as far as I know, the majority of the notions (Scheduling, Activation, Conflict resolver, …) are EVM specific. So it is unclear whether this set of features is really VIATRA-specific or rather EVM-specific. (To formulate it another way: are we sure the org.eclipse.viatra namespace is a good choice for this functionality?)
> 
> In my opinion, we should stick to the original design (where VIATRA is mostly a language/internal DSL/API over EVM, the execution engine) as much as possible - which in this case would mean that this work possibly needs to be broken down into EVM-specific (“runtime”) features and, if necessary, an end-user VIATRA API extension.
> 
> cheers
> Istvan
> 
> On 24 Sep 2015 at 10:40:47, Ujhelyi Zoltán (ujhelyiz@xxxxxxxxxxxxxxxx) wrote:
> 
>> Hi,
>> 
>> just a clarification to see what we are aiming for: we are extending the VIATRA transformation API with features that support debugging, in other words, options to see and/or influence the decisions made by the virtual machine.
>> 
>> We already have a low-level infrastructure in place (these are the adapters Péter mentioned), and we are looking for some use cases to demonstrate its usefulness. We already have found some (available at the wiki page), but if someone has some idea, we would be glad to think over/incorporate it.
>> 
>> @Péter: some minor remarks. First of all, feel free to be more casual in the list, we all know each other. Additionally, for the diagram in the wiki page, please, use the new VIATRA logo (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=471648 for details).
>> 
>> Cheers,
>> Zoli
>> -- Zoltán Ujhelyi
>> 
>> Technology Expert
>> IncQueryLabs Ltd.
>> 
>> > On 23 Sep 2015, at 22:15, Lunk Péter <lunkpeter@xxxxxxxxxxx> wrote:
>> > 
>> > Greetings,
>> > 
>> > My name is Peter Lunk and I am a newly elected committer on the VIATRA project. At first, I'd like to express my thanks to all of you for granting me this status, I hope my contributions will prove to be useful in the future.
>> > 
>> > Under the supervision of Zoltán Ujhelyi, I have been working on a framework that enables the addition of auxiliary features to VIATRA based event-driven transformations. I have summarized the motivation and high level architecture of this framework in the following Eclipse wiki page: https://wiki.eclipse.org/VIATRA/Transformation_API/Adapter_Framework
>> > 
>> > In a nutshell, the framework operates in the following way:
>> > • Auxiliary functionalities that aid the development of event-driven transformations are implemented as a set of VIATRA transformation adapters.
>> > • The transformation adapters contain callback methods which will be called at certain points during the transformation.
>> > • These Adapters are assigned to Adapter Configurations, which represent a major use case (e.g.: transformation debugger).
>> > • Adapter configurations are added to an EVM Executor which will call their callback methods. (e.g.: Before the execution of a rule activation).
>> > • The VIATRA event-driven transformation is initialized using the Adapter Supporting EVM Executor.
>> > 
>> > In the wiki page mentioned above, I have included a number of typical use cases that can be implemented using this adapter based approach. I would like to ask you to take a look at the project, and if you have additional use case ideas that could be useful during event-driven transformation development, feel free to share it with us, every idea will be much appreciated.
>> > 
>> > Thanks in advance,
>> > 
>> > Peter Lunk
>> > _______________________________________________
>> > viatra-dev mailing list
>> > viatra-dev@xxxxxxxxxxx
>> > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> > https://dev.eclipse.org/mailman/listinfo/viatra-dev
>> 
>> _______________________________________________
>> viatra-dev mailing list
>> viatra-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/viatra-dev
> -- 
> István Ráth
> Research Fellow
> Fault Tolerant Systems Research Group
> Budapest University of Technology and Economics
> http://inf.mit.bme.hu/en/members/rath
> rath@xxxxxxxxxx
> _______________________________________________
> viatra-dev mailing list
> viatra-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/viatra-dev



Back to the top