Implementation structure

[JannesBrands]

Hey guys,
yesterday night I tried to get a general view of what is already existing / working.
I faced some mocks that are used but does not exist concretely and I did not know
if there is a plan or how we want to structure the stack. So if there is not already another
idea, I would start with an idea of a strcuture:

Path

• Datalink-3
• Network-4
• NetworkManagement-5
• VirtualTerminalClient-06
• ApplicationMessages-7
• TractorECU-9
• TaskControllerClient-10
• DiagnosticsService-12
• FileServerClient-13
• SequenceControllerClient-14
• Common

That would be my idea, even I am not sure to maybe combine 3, 4, 5.
It is based on 2 other Isobus drivers that already exist and are used commercially.
Even if this is now actually not a big idea cause its actually only derived from the standard. But I also see the advantage in this, namely the overview, since everyone who has worked with the standard will find their way around much more easily. If I specifically search for something in the driver and the part 11783-06 is divided into several folders like ObjectPool, VtCommunication... I think it is a bit harder to find the things.

I would be curious to read about your thoughts, that we have a discussion about it and are ready to start with an united idea.

@ad3154
@GwnDaan
@Thom-de-Jong
@Notgnoshi

[JannesBrands]

Also I would suggest that we create some pullrequests as they are already existing and mark them like @GwnDaan did, with the label referring to the structure like TaskControllerClient-10 and maybe a reference to the ISO 11783 that describes and defines the feature. I think we need to get a little more organization into this for the community that contributes. Like in my case I don't got the time to work on it every night and maybe even with some breaks of 1 or 2 weeks and it's hard to get started again if you didn't track close the process. And anyway it would be helpful for the guys of Raven (or I don't know if there is already an internal planning process @ad3154 @Notgnoshi).

[ad3154]

I would be fine with us adding labels like that if you'd like. I think naturally some work will cross these boundaries, so the practicality of it may be not be 100% perfect but it will at least help identify the major components of issues and PRs.

Regarding the structure you proposed, I think some of those things probably make sense to break up by standard, I would be fine with that personally, though I'd like to hear others' opinions as well. The high level pieces (things like TC, VT, sequence control) especially seem like good candidates for such a structure.

I personally think Datalink, Network, and Network management will inevitably have to be combined, as they are very tightly integrated with each other and require a lot of coordination between them.

Lastly, apologies that progress has slowed a little. We're currently off of our innovation sprint at Raven, so this is a lower priority at the moment, and I have to focus on the C++ stack in my free time as well.

For this stack, I think we should really prioritize closing out/merging the open PRs so that we can keep moving forward with integrating the things at the Network layer with what we've already started for the Datalink layer with address claiming. Plus, we should keep integrating what we can recycle from @Thom-de-Jong, as he has a lot of good stuff that can get us a head start on VT and other high-level protocols.

[JannesBrands]

Yeah, I was thinking the same way about combining that network management. Maybe another idea would be splitting it between the CAN and J1939 level or something called "core" and "base".

[Notgnoshi]

And anyway it would be helpful for the guys of Raven (or I don't know if there is already an internal planning process

We do not have an internal planning process for this. I think whatever we do, it should be public here on GitHub (i.e., Discussions, Issues, Projects, etc).

I think we need to get a little more organization into this for the community that contributes.

Agreed. @ad3154 and I both believe that the Open-Agriculture community is incredible, and we should definitely work to ensure community openness and stewardship. I think what @ad3154 has suggested (finishing open PRs, and building out the Network and Data Link layers) is appropriate to start with. I'm not a subject matter expert though, so I am intimidated by attempting this myself :)

with the label referring to the structure like TaskControllerClient-10 and maybe a reference to the ISO 11783 that describes and defines the feature.

I like this!

[JannesBrands]

There is no reason to be intimidated :). Grab the standard and try what you can. The best feeling is when you can try it out on the field later. I think that's what makes the agriculture community, too. More and more young people are coming in who have grown up in the agricultural environment and are very visceral technically.

[GwnDaan]

Hee, I wanted to hop in here as well, sorry for being so late haha.

I saw you made nice initial suggestion in #26, but there are a few things I feel like would be clearer in another form:

1. I feel like data_link can still be separated from network_management. They can may still be interconnected, but having a dedicated folder for data transfer can help in getting it more organized.
2. The 'part numbers' in the folder structure seem bit redundant and counter intuitive. I think only using the 'tags' for issues/PR's with the numbers is enough and keeps the naming more consistent throughout the Rust ecosystem. (I personally have rarely seen any numbers used in paths)
3. Don't separate client/server, they overlap a lot, like really a lot. So for example the object pool of a vt client should be found in the same directory as the vt server.
4. Have a dedicated 'hardware' folder (for everything hardware related, e.g. the driver implementations, or sensors or whatever there might be coming in the future)

My suggestion of the paths:

• hardware_interface
• data_link
• network_management
• virtual_terminal
• application_messages
• tractor_ecu
• task_controller
• diagnostic_service
• file_server
• sequence_controller

Let me know your thoughts 😄

[JannesBrands]

Yep, Ill be there too for one or two days. Probably on monday and saturday.
Lets interconnect to dont spam these topics full with off topic stuff.
Maybe it is possible to put the link into the description, as far you agree on that @ad3154
I think this would be a good opportunity.
@Notgnoshi
@GwnDaan
@Thom-de-Jong

t.me/openagriculture

[ad3154]

I guess Discord is my first choice for something like that if that's an option for you. Most of the other open source communities I follow seem to be on there, like SerenityOS and it's convenient to be able to categorize chats (such as C++ stack versus Rust stack versus random other stuff).

But at the same time, if telegram is easiest for the community I'm willing to download it, haha.

https://discord.gg/FPkNqNHR4j

Either way, if we take some amount of discussion off-platform we'll want to remain vigilant about making sure issues and ideas end up on GitHub as the source of truth for what works needs doing and who's doing it.

[GwnDaan]

it's convenient to be able to categorize chats (such as C++ stack versus Rust stack versus random other stuff)

Yeah, with telegram you can do that as well. I think telegram is a little bit more used inside the agriculture community but in the end I don't think it'll make a difference

[ad3154]

OK, I'll grab it then

[JannesBrands]

We need some opinions how we continue on this to maybe change some things of #26 and merge it.

To give you my opinion:
Im open for @GwnDaan's suggestion:

hardware_interface
data_link
network_management
virtual_terminal
application_messages
tractor_ecu
task_controller
diagnostic_service
file_server
sequence_controller

Now that some time has passed and I've gotten more involved with Rust, I would agree with @GwnDaan's suggestion due to the formatting matching Rust.

Just give this post a thumbs up if you agree and I'll change it tomorrow so that the pull request can also be merged or let me know if you have any other idea.
@ad3154
@Notgnoshi
@GwnDaan
@Thom-de-Jong