Hi,
about this part "write the smart contracts in Solidity, i.e. the Catalog Contract, the Base
Content Management Contract and each single Content Management Contract
and compile/deploy them on Remix " i don't understand the meaning of the last part "each single Content Management Contract ".
What we have to do about this part?
Thanks
You have to simulate the system, so make up a bunch of authors and contents. Each content will need a content manager contract. This is the emaning of "each single Content Management Contract ".
So only for the simulation? The authors are simply EOA? And for the content i have to instatiate some Content Management Contract?
What do you mean "only for the simulation"? While the system is running there will be a set of content mangers contracts controlled by EOA authors. You need to simulate this to do some tests on remix, but it is how it should be in a real deployment.
Thanks
Might be (depending on your implementation). In theory the "base content manager" is supposed to provide the required data/functions only, to be extended by authrs in their ontarcts with all the additional functionalities they need. Also a general base contarct alone might not be specific enough for the general case. For example how you manage the content consumption? Is it not left to be specified to the contract author? I guess this works fine for the simplified final term, but what about the final project?
I'm not the original poster, but I have the same doubts.
Right now, I have the BaseContentManager contract which holds all the needed data (e.g. genre, author, unique description) and functions, but is made abstract so it can't be deployed "as-is" and must be extended. Then I imagined several "categories" of content (e.g. movie, song, ebook, image) and made a contract for every category with additional metadata: for example the "movie" contract has a bitrate, a width, an height, a duration and so on. The actual content is seen in the base contract as a byte array for maximum generality, but each category can store it however they want - when an user requests the consumption of a content, it is up to the category contract to present it as a byte array. (In practice, for simplicity, in each category the content is stored simply as byte array that is returned as-is.)
I thought this solution so that authors:
i have a doubt about this implementation: the genre requested for exemple in GetLatestByGenre(x) is a different thing respect to the "type" of the contract?
Yes, in my implementation the genre is a field of the base contract manager and is in principle totally separate from the "category".
Well, in my implementation they're the same because otherwise I think that Get*ByGenre(x) will be a little messy. I mean, generally genre stand for something like "Action", "Thriller" and so on for a movie, for songs you'll have different genres and either for books, but generally you have different "catalogs" for different categories (music, movies, books etc); here you have a single catalog and, in my opinion, those getters are a way to discriminate among them.
But I don't know if this reasoning is correct!
Yes, this is just a slight alternative to mine, but I think it's equally correct!
My implementation is more or less the same and those "categories" are deployed by the author with their input parameters (title, author and peculiar parameters).
I also thought that having a standard way to "create" specific kind of contents would be more easy easy to use both for authors and for customers.
This maybe limitates the "freedom" of an author, but it allows to have a standard way to consume contents and I thought that also for the complete DApp that would be better!
Is it reasonable?
Yes, it is the same reasoning that I've made, plus a picky author can always extend the base management contract to implement its own category (but ideally one should choose between the provided categories).
1) Given a base content manager contract you have two different approaches, either you "instantiate" such contract for each content OR you "expand/overwrite" it with for each content. Of course you have more flexibility in the second case, but still, if the base contract is implemented correctly (i.e. general but detailed enough at the same time), the first solution works as well. So, what it looks like you are doing (first case) IS NOT wrong (as long as it is done properly...).
2) Representing a content as a (string or byte array) for simplicity is perfectly fine as lon as it works properly with the consume content operation. Any simple and sound implementation to simulate content consumption is fine.
3) As always try to
keep it simple. As discussed with some of you during question time,
the genre is just a label to categorize the content. It can be
action/drama/... for a catalog about movies or music/film/... for a
generic content catalog. It does not really matter, it is just used
to test how you manage such labels. For the sake of the exam you can
also call the content "pippo, pluto, ..." and the genre be
"genre1, genre2, ..." . DO not waste time or complicate
your code to consider subgenres, i.e. genres specific for each
category of content (e.g. action/drama/... if content is a movie,
pop/rock/... if it is music, etc). As always, the more the better, but in this case it really seems a superfluous overcomplication (at least for the final term, it makes more sense for teh final project).