Architectural layer diagrams and subprojects

Development
1

I’m making progress on building maidsafe. I have started to build the other subprojects and to study the dependencies of subprojects on each other as a method to get orientated as to who is doing what for whom.
To this end I found some layer diagrams in various documents:Im trying to reconcile these in my mind.

maidsafe layer diagram from “The Architecture of the SAFE Network”

These is also a layer diagram on http://maidsafe.net/core-developers that is somewhat different.

Based on my own experience, I know that in the development of any project of any size there are design shifts as the people get smarter. The first question I have is which one is newer or more accurately reflects the current thinking.

Is it safe to assume that a subproject and a architecture layer are roughly the same?

I have drawn a quick dependency tree from cdash to help in my edification.
There may be mistakes since I created it by hand by looking at cdash screens. Im not smart enough yet to derive the dependency data directly from git.
Below are two views of the same tree created from the cdash subproject dependency screens.
and

A couple of things have surprised me:

  1. The “Third Party” subproject does not have any dependencies on any other subproject. I would have thought that it would use the top most subprojects or at least the API.

  2. What is the role of CRUX? Is it an alternative to or refactor of; rudp and passport. I ask this based in where it is in the dependency tree.

  3. Im confused about the subprojects vaultManager vs vault_manager; Note the underscore in the name. Is one the vestigial remains of a rename/refactor or a future version. Which is which?

  4. I’m guessing that a subproject roughly corresponds to a layer and that common is not really a layer but a library of stuff used by all layers.

  5. I am surprised at the amount of interconnection between subprojects. They seem more like functional islands and not really layers.
    .

  6. I wonder where the utilities are like local_network_controller?

  7. How come only launcher has a dependency on encrypt? I would not have guessed that.
    8)Could launcher be thought of as an third party app that is being done in house?

  8. Are there any class diagrams or documentation, like javadoc or doxygen?
    I guess it would actually be cppdoc:-)

So many question. I’m just starting to figuring out where maidsafe fits in the world of DAO, a new acronym to me, and where I might fit in maidsafe and in the DAO world in general.
sorry for the dump but thank you for your time.

4 Likes
2

I think you must have the devs having a pow wow on this one…good stuff :smile:

3

Nice work, great to see.

I created a dependency map from github and it’s incredibly complex. In fact if you use cmake you can output dependencies to a graphviz output which does this to. If you try with any c++ projects (try boost you will fall over looking at the dependency hell they expose :slight_smile: )

That is good these are things we use so we depend on them in a one way relationship.

It will replace rudp

Think you may be seeing this in a cdash view (cdash can be manipulated so you can add more names conventions, it’s not great there really.

Yes on both counts, common is really common utilities and includes test only utils as well.

The interconnection is OK as long as there is not to much bidirectional interconnection as that breaks any layer approach. We do have that BTW with async_return and callbacks in places.

Many utilities live in sub directories of projects, local network controller I think is in vault, we have a lot of binaries for different purposes. Routing_v2 removes local network controller.

Anything close to client will depend on encrypt for data content, I am not 100% sure about the launcher but the guys will know.

Yes it can, others can create their own, the purpose here is to make it as simple as possible to build on the API’s safely, it will never be a hard requirement though. So a helper really, but may become defacto who knows?

Not really you can autogenerate it, but as we use a lot of templated code like debugging templates this kind of documentation gets very stale very quick and is way to complex. I personally do not like javadoc and c++ version which is really docugen as it feels kinda lazy at times and irrelevant at other times (what I mean is we strive for well named interfaces and variable names, it’s not easy though). I think boost and Qt do a good job at their docs though, in boost you need high quality docs to get a lib in, of course after that its more difficult to ensure they are up to date.

I am playing with rust just now which actually compiles docs and tests examples in them, which is a really nice feature. Maybe watch this space.

The best most solid approach is to look at header files, they should be mostly documented and then tests show implementation.

I am less concerned with the DAO stuff, its another term for something that may look like nothing else and not what it is today etc. Main thing is move froward and this is a great first step, real deep investigation and I love it :wink: cheers again

1 Like
4

thanks for the input. I have so much to learn

2 Likes
5

At this rate not much and not long :slight_smile: again nice work, mucho appreciated

6

The diagram in the core developers page of the website is not up to date with the recent changes. The layer diagram from “The Architecture of the SAFE Network” is the correct one.

7

thanks, Im a picture person so I look for diagrams where I can find them and draw them when I cannt find them.