i have two question:
1) it's ok in the Content Managment Contract to have only the data of the content and the getContent function and all others info saved in the Catalog Manager?
2) About retrive the data of the content an user payed for, it's ok to call getContent from the Catalog to the Content contract, so that Content contract send data to Catalog that send the data to the user?
Thanks.
1) There is no wrong solution, as long as you can explain and justify the choices made (and they make sense). In this case your appoach seems strange form a "semantic" point of view, since each contract should be a closed agen managing its own functionalities and data. So conceptually you should insert all functions and data belonging to the content alone inside its manager contract. Your soution also looks too minimal to work properly, I cn think at at leat one other thing that probably must be inserted only in the content manager and not in teh catalog.
This said it greatly depends what you mena by "data of the content"...
2) This seems forced by your implementation design relying on the heavy catalog. It makes way more sense (and should be) that teh catalog does not get involved in content fruition.
Thanks
Be careful that getContent and access a content are different things. I think that getContent is used in the catalog to buy a content, and the access of this content is provided by the content itself.
That is correct. Consume and AccessGranting are independent (as long as "Consume" happens after "AccessGranting"). Your sentence "granting content permission is managed by the Catalog and the check of the permission is managed by the content contract" is exactly how it should be. Customers should call "GetContent(x)" on the catalog contract and "Consume(x)" on teh content manager contract.
In reference to this sentence:
It makes way more sense (and should be) that teh catalog does not get involved in content fruition.
I assumed that a content knows the address of the catalog. This is necessary to be sure that the content access is allowed only to users who have acquired the license. This operation can be made in 2 different ways:
In both cases the content needs to know the catalog address: in the first case to contact it, int the second one because it needs to trust only the catalog. Indeed, the function must be public, and the content must to be sure that only the catalog can call it, otherwise everyone can add itself as granted user.
So, the catalog should not serve the content, but I do not understand how he can not be involved in the content fruition.
Thanks in advance for clarifications.
Again, Consume and AccessGranting are independent (except time constraint). By "content fruition" I was talking abut consuming the content, and, as explained in the previous answer this is done between customers and contents managers without catalog intervention. Or at least that is how we envisioned it, if you have a different approach and feel confident you can prove it's reasonable go with it.
About the address the content DEFINETELY needs to know the catalog address, at least to verify it's talking with it (as you said in the end).
The catalog only manages AccessGranting (and so payments), then provides the user with the needed information (depending on your impelmentation) to reach the content. Then the customer can Consume ("conetnt fruition") the content directy from the content manager without further need for the catalog.
Is it clearer now?
Yes, now it's clear. Thank you for your answers.
Yes, it's clearer.
Another doubt, if a premium user call GetContentPremium(x) for access granting for content x, can consume the content after the premium validity or not?
Thanks
It is up to you to choose. Both solutions can be defended, due to the fact that premium accounts can be exploited to "abuse" the system. In general I would say that 'yes' mkes more sense, but 'no' is safer and cheaper.
Yes) You can say that once it has requested access a premium account needs to be treated as any customer, so it has the option to consume the content independently at any future time.
No) After the premium validity expiration he cannot consume content any more. This is in contrast with the decoupled AccessGranting/Consuming model, but it makes sense to prevent a premium user to actually pay a premium fee to be able to consume once any content ever created to that point. In fact it can spam access granting requests to all the content and consume in the future only when/if it is interested. This can result in an unnecessary bloat of the involved smart contracts with mostly useless data.
Premium accounts can be tricky (i.e. lead to exploits) so they were left to student interpretation accordingly to allow you to tune them depending on your implementation.