Refactored code pushed to GitHub

[Johannes Klug]

Dear developers,

I've pushed "hbird" to GitHub:
https://github.com/JohannesKlug/hbird

This repository contains the code Mark and I refactored over the past
months. It also includes the assembly we used for the Thunderbird launch.

Note that the hbird repo currently mainly contains transport-level code.
If you'd like to add to it, "fork" it on GitHub, and integrate what you
think needs integrating. When you're happy with your results, send a
message, and issue a "pull request" in GitHub, so we can merge your changes.

If you've got any questions about the "hbird" code base, let's discuss
those on the list.

Mark and I will write down our thoughts about the new design shortly,
and share them on this list.

Cheers,
Johannes

[Mark Doyle]

I think there is a very good argument to keep business layer components in their own repository. That way an entire set of related components can be crafted and released together. The only dependencies on the transport layer are the space system model (assuming you want encoding/decoding) and the (soon to be separated out) exchange types.

It also means anybody wishing to create a new business layer app need not check out the entire codes base and vice versa.

Thoughts?

[Gert Villemos]

I agree.

I would also like to create a better modulization in the business tier. We are not far of right now, but its not consistent. I have been thinking along the lines;

1. Create a module per 'service'. A service is nothing more than a definition of input/output messages and a textual description of the exchange protocol. Only POJOs with text. Service modules may depend on each other. This is basically a 'type library'.

2. Create a module per 'provider'. Each provider depends on the 'service(s)' it implement(s).

As an example;

The 'navigation-service' module defines the types such as 'PredictOrbit', 'Location', 'OrbitalState' and 'ContactEvent'.

The 'navigation' module depends on the 'navigation-service' module and implements it, for example using OREKIT. 

Cheers,

G.

---

Von: Mark Doyle <markjo...@googlemail.com>
An: humming...@googlegroups.com
Gesendet: 0:28 Donnerstag, 24.November 2011
Betreff: Re: Refactored code pushed to GitHub

[Mark Doyle]

Perhaps a simple Maven archetype would suffice. It could import the basic hummingbird-core artefacts and write two "hello world" classes, one for telemetry in and one command out.

[Gert Villemos]

Yep. 

Perhaps we can 'smarten' the existing Hummingbird archetypes up, i.e. for example as part of the archetype wizard, let people select which 'services' they will provide / use, then setup the POM accordingly and make the 'boiler plate' classes for receiving and processing these types.

That would be cool.

Cheers,

G.

---

Von: Mark Doyle <markjo...@googlemail.com>
An: humming...@googlegroups.com

Gesendet: 14:36 Donnerstag, 24.November 2011

[Johannes Klug]

On 11/24/2011 09:08 AM, Gert Villemos wrote:

I agree.

I would also like to create a better modulization in the business tier. We are not far of right now, but its not consistent. I have been thinking along the lines;

1. Create a module per 'service'. A service is nothing more than a definition of input/output messages and a textual description of the exchange protocol. Only POJOs with text. Service modules may depend on each other. This is basically a 'type library'.

2. Create a module per 'provider'. Each provider depends on the 'service(s)' it implement(s).

As an example;

The 'navigation-service' module defines the types such as 'PredictOrbit', 'Location', 'OrbitalState' and 'ContactEvent'.

The 'navigation' module depends on the 'navigation-service' module and implements it, for example using OREKIT. 

I've thought about this for a while now, too. Your idea sounds like the only reasonable solution, I think.

Consider the "core", or whatever we call it. Should we mandate that it contains the interfaces for every supported service? I think it can't, and it shouldn't. Splitting off interface and implementation for every module makes sense. If we then write a config parser (XTCE, MIB, whatever) that can provide configuration for specific services, we need to pull in their interfaces (data type definitions) as a dependency. This will result in fine-grained, cohesive building blocks. I'm voting in favour of this.

Johannes

[Villemos, Gert]

Exactly; a separate module per service. We get a lot of service modules, but first of all I do not think that is a problem and secondly we simply make a 'all-service-modules' module that includes all service modules for the lazy bastards (like me) that dont care. Camel and Spring does the same, i.e. you have a 'all' module.

I'm right now implementing the control of the Lego-bot and will refactor the business tier as I go along.

Cheers,
G.




-----Ursprüngliche Nachricht-----
Von: humming...@googlegroups.com im Auftrag von Johannes Klug
Gesendet: Do 24.11.2011 21:01
An: humming...@googlegroups.com

Betreff: Re: Refactored code pushed to GitHub

Think green - keep it on the screen. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

[Johannes Klug]

On 11/24/2011 09:16 PM, Villemos, Gert wrote:

Exactly; a separate module per service.

Plus: once the interfaces are extracted from their implementation it becomes quite easy to develop competing or just different implementations of the same "service". Great for a marketplace!

[Villemos, Gert]

That was why I first gave it a serious thourght and thourght about how to 'modulize' the system. The last months massive discussions were very good.

Cheers,
G.


-----Ursprüngliche Nachricht-----
Von: humming...@googlegroups.com im Auftrag von Johannes Klug

Gesendet: Do 24.11.2011 22:04
An: humming...@googlegroups.com
Betreff: Re: AW: Refactored code pushed to GitHub