Skip to content
This repository has been archived by the owner on Dec 14, 2021. It is now read-only.

Rethink the definition of a packet #38

Closed
KtorZ opened this issue Feb 16, 2016 · 2 comments
Closed

Rethink the definition of a packet #38

KtorZ opened this issue Feb 16, 2016 · 2 comments
Assignees

Comments

@KtorZ
Copy link
Contributor

KtorZ commented Feb 16, 2016

What we call a packet at the current moment is fixed over time and for every component.
That approach is too both too restrictive and wrong. Packet has to evolve over time and each component is contributing to those changes. At the end (after a handler publish it to an application), a packet should be way more than it was when received by a router.

@KtorZ KtorZ self-assigned this Feb 16, 2016
@KtorZ KtorZ added this to the Sprint #1 milestone Feb 16, 2016
@KtorZ
Copy link
Contributor Author

KtorZ commented Feb 18, 2016

The remark also stands for registrations.
Looking at the broker storage, an entry is defined the following way:

type brokerEntry struct {
    Id      string          
    NwkSKey lorawan.AES128Key
    Url     string         
}

which in itself almost implies an http protocols (through the Url attribute). The abstraction should be raised up a little bit to let the adapter decide completely how to transfer a message given an option param.

@KtorZ
Copy link
Contributor Author

KtorZ commented Feb 29, 2016

done cde7515.

@KtorZ KtorZ closed this as completed Feb 29, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants