search

reTHINK-project / core-framework

The main goal of WP3 is to provide the reTHINK core framework comprised by the runtime environment where Hyperties are executed and the messaging nodes used to support messages exchange between Hyperties.
Apache License 2.0
1 stars 0 forks source link

Crafting the Service Framework #49

Closed acheambe closed 9 years ago

acheambe commented 9 years ago

As the runtime architecture(T3.2) and QoS(T3.3) mature, we need to resume the discussions on defining and specifying the Service Framework.

Initial direction

We started looking at the different Web JS Frameworks (WJF). However, i think this information so far is suitable for the SoTA section. The service framework to my opinion will need to go beyond that. I look at it like a wrapper layer on top of the runtime and Qos components offering an abstract API to developers.

Thus, i will like to open the discussion about that especially with the partners involved. But anyone can join in this discussion if you feel like.

Requirements of the SF:

To have some structure to our discsusions, here are a few open questions i have, and please feel free to add yours too.

Open Questions

1) What is the difference between the functionalities on the runtime and the SF? The line between the two is very thin, we need to identify, choose what functionality fits best where? 2) Which WJF(Meteor, StapesJS, Backbone, etc) is your preferred framework of choice? 3) To what extend should the WJF be used in defining the reTHINK JS Service Framework. 4) What core components functionalities should the Service Framework provide to the developers?

pchainho commented 9 years ago

In general I agree with your interpretation: the main objective is to provide a SDK tool to facilitate the development of Hyperties ie, higher level API on top of Runtime APIs already targeting some specific types of Hyperties including Communication, Context and Identity Hyperties.

A good idea already given by you, Alice, was to provide some kind of template to be used "a la" Angular.

1) What is the difference between the functionalities on the runtime and the SF? The line between the two is very thin, we need to identify, choose what functionality fits best where?

As mentioned above it will be an higher level API on top of Runtime APIs that could be designed to target some specific Hyperty types. Only after we close the Runtime design we can start designing the Framework APIs. And the Framework APIs are not mandatory ie developers are free to directly use the Runtime APIs.

2) Which WJF(Meteor, StapesJS, Backbone, etc) is your preferred framework of choice?

At this point we have no preference. We should just note that some could not be compliant with Hyperty Runtime eg I understand Meteor as a dependency on the backend server (node.js)

3) To what extend should the WJF be used in defining the reTHINK JS Service Framework.

Good point. Ideally Hyperty Framework would be agnostic of these existing WJF to still let developers choose the ones they prefer. But I guess this would diminish the benefits we want to have in terms of abstraction and time to market.

4) What core components functionalities should the Service Framework provide to the developers?

Still too early but one idea would be to start with specific development use cases eg start a new type of Hyperty development, extending an existing Hyperty type eg communication, adapt existing non-hyperty services, hyperty widgets, ...

shumy commented 9 years ago

My point of view on this is: The rethink runtime should only provide the M in the MVC pattern. The application can interact observing and setting changes in the model. It seems like polymer-project is using the Object.observe API when available. We could try an integration experimentation with this.

acheambe commented 9 years ago

Thanks @shumy for your feedback.

The rethink runtime should only provide the M in the MVC pattern. The application can interact observing and setting changes in the model.

Did you mean framework here (the framework should only provide the M...)

It seems like polymer-project is using the Object.observe API when available. We could try an integration experimentation with this.

Yes, polymer uses that, i started playing around their API's to see what can be useful/re-used. However looks like their implementation is based on ECMAScript v5 (we are targeting v6/v7?) And for Object.observe some browsers like chrom and opera have it already integrated. So if we are considering polymer API, it will be for browsers/runtime without the implementation

shumy commented 9 years ago

Will it work for browsers without the implementation if we provide a Polyfill? Can we observe an object at the same time as the polymer? So that we can receive reports of changes made by polymer.

acheambe commented 9 years ago

I suppose so. We could do so experimentation tests here.

acheambe commented 9 years ago

Closing this discussion. It is more or less now clear how to proceed with the service framework.