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

Application vs Hyperty: clarify #110

Closed pchainho closed 8 years ago

pchainho commented 8 years ago

@sbecot I see 2 service providers and 2 sandboxes. Sorry, but I’m a bit puzzled. What is the difference between the Hyperty and the application? Could you explain what is an Application provider Sandbox, and the difference between an Application Service Provider and a Service Provider that build Hyperties?

At https://github.com/reTHINK-project/core-framework/blob/master/docs/specs/runtime/runtime-architecture.md

sbecot commented 8 years ago

Still not clear to me. If I refer to D1.1 (§2.5)

“Application Providers” are entities that provide software to a broad range of users A Service Provider may provide different types of services like Communication Services, Identity Management Services, Connectivity Services

If I refer to D2.1

The Application Service Provider (ASP) represents an organization that offers web applications or terminal based applications to a service consumer. Then it is explained that a CSP can also be an ASP.

These are business roles: nothing technical. Then, in the D3.1 I read that an Application is different than a Service. What is underlying, is that as Service means an Hyperty, but not an Application. If it is the case, if there is a technical distinction between Service and Application, or if a Service=Hyperty, it would be nice to explain it. But this raises 2 questions:

pchainho commented 8 years ago

I've just updated https://github.com/reTHINK-project/core-framework/blob/master/docs/specs/runtime/runtime-architecture.md with an attempt to clarify this issue

sbecot commented 8 years ago

Hi, I understand better what you mean, and this is not so important, but still, I have 3 remarks:

According to Hyperty Definition introduced in D2.1 [38], an Hyperty is a web software that can be reused by Web Applications through a local (Javascript) API (the Hyperty Application API), which is not subject to standardisation.

1-> This is not what is stated in the definition you refer to. You introduce much elasticity in the interpretation.

Hyperty is delivered by an (Hyperty) Service Provider and the Application is delivered by an Application Service Provider

2-> You should avoid to introduce new roles and new concepts on the fly. We didn't make any difference between Service Provider and Application Service Provider before.

3-> Even if I understand what you mean, I think the distinction between Web Apps and Hyperty is useless, as Application sandboxing is handled as Service Sandboxing.

pchainho commented 8 years ago

1-> This is not what is stated in the definition you refer to. You introduce much elasticity in the interpretation.

Hyperty is delivered by an (Hyperty) Service Provider and the Application is delivered by an Application Service Provider

Yes, the Hyperty Service Provider was not formally defined before but it was mentioned several times.

2-> You should avoid to introduce new roles and new concepts on the fly. We didn't make any difference between Service Provider and Application Service Provider before.

It is still valid to me that an ASP is a Service Provider.

3-> Even if I understand what you mean, I think the distinction between Web Apps and Hyperty is useless, as Application sandboxing is handled as Service Sandboxing.

We really need that distinction when Apps and Hyperties are not provided by the same Service Provider. Eg in the browser implementation, what we are planning is to have Apps outside an iFrame while Hyperties and protostubs will be Web Workers inside an iFrame

sbecot commented 8 years ago

I can understand this, but your statement of 4.1 is useful in 4.5.1, more than 40 pages after so the relation is not easy to follow. Your implementation choice is rising up to the specifications which is a bit weird. I would prefer to mention something like an App could be composed of "managed code (including Hyperties)", and "not managed code", or something more related to the implementation, not to mix design and specs. By the way I didn't see anywhere before that Hyperties where not supposed to show any interface.

And I still consider that elasticity in interpretation of definitions can be a problem.

By the way, this is not really a major issue, and at this stage we have to finalize the doc, so I won't struggle more on this.