Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Contribution of MongoDB-based device registry 
I am not sure what you are now going to do or want to do. Is there anything else you need from me?

Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

________________________________________
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> on behalf of Lohmann Carsten (INST/ECS4) <Carsten.Lohmann@xxxxxxxxxxxx>
Sent: Friday, March 31, 2017 14:01
To: hono developer discussions
Subject: Re: [hono-dev] Contribution of MongoDB-based device registry

PS:
> The created jar and docker-container get a name hinting at the mongodb support.
Thinking more about it, I think it's better to keep the original name.
Otherwise names get too long when more possible "mix-and-match" features get added.


________________________________________
Von: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> im Auftrag von Lohmann Carsten (INST/ECS4) <Carsten.Lohmann@xxxxxxxxxxxx>
Gesendet: Donnerstag, 30. März 2017 16:50
An: hono developer discussions
Betreff: Re: [hono-dev] Contribution of MongoDB-based device registry

> Good question. My concern would be (with getting more alternative
> implementations) that it would bloat the server artifact but people would usually
> use only one implementation so it would probably be a good idea to have these
> alternative implementations in separate modules so that users can mix and match
> (by declaring dependencies and using the corresponding Spring profile name).

Yes, good point.
What made me hesitate to go that way was thinking whether this might add unwanted complexity to the hono-app setup.

With a separate "hono-registration-mongodb" module, the question is whether to include that in the "hono-app" module and in the created spring-boot-jar.
To be flexible and really reduce potential bloat, we would need to add support for building different artifacts there.
I could imagine doing this by adding the "hono-registration-mongodb" dependency only in connection with a new "mongodb" maven profile.
The created jar and docker-container get a name hinting at the mongodb support. In the "example" module we can add a special docker-compose file for this case (with added configuration properties and we could start a mongoDB docker image there as well).

I could try that if it sounds sensible to you.

Carsten




________________________________________
Von: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> im Auftrag von Hudalla Kai (INST/ECS4) <kai.hudalla@xxxxxxxxxxxx>
Gesendet: Donnerstag, 30. März 2017 13:54
An: hono-dev@xxxxxxxxxxx
Betreff: Re: [hono-dev] Contribution of MongoDB-based device registry

On Tue, 2017-03-28 at 15:30 +0000, Lohmann Carsten (INST/ECS4) wrote:
> Hi,
>
> we would like to contribute an alternative device registry implementation based
> upon storage in a MongoDB.
> Our intention was to have a device registry that can be used in a Docker Swarm
> setup with multiple Hono server instances (which is not the case with the
> current FileBasedRegistrationService).
>
> Is there interest in such a solution?
>

Sounds great :-) I think this would be a great addition.

> Regarding the implementation:
> These additional dependencies are used:
> - vertx-mongo-client
> - Flapdoodle Embedded MongoDB (Apache License 2.0) - used for an integration
> test
>
I have taken a look at the transitive deps as well, this shouldn't be a problem
...

> We would add the implementation to the Hono server module (alongside the
> current FileBasedRegistrationService) and have the MongoDB registration service
> be selectable via a spring profile.
> Or are there other suggestions on where/how to add it?
>
Good question. My concern would be (with getting more alternative
implementations) that it would bloat the server artifact but people would usually
use only one implementation so it would probably be a good idea to have these
alternative implementations in separate modules so that users can mix and match
(by declaring dependencies and using the corresponding Spring profile name).

> --
> Best regards
>
> Carsten Lohmann
>
> Bosch Software Innovations GmbH
> Schöneberger Ufer 89-91
> 10785 Berlin
> GERMANY
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/hono-dev
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev

Back to the top