Refactor guid, message, queue #626
Conversation
first, we make the GUID library publically usable. This requires a few other needed changes that are also useful in their own right, basically make small packages unaware of the things that implement them. I.e. GUID's need not be aware of the messages using them, and messages need not be aware of the queues using them.
| @@ -9,4 +11,5 @@ type BackendQueue interface { | |||
| Delete() error | |||
| Depth() int64 | |||
| Empty() error | |||
| WriteMsg(buf *bytes.Buffer, msg *Message) error | |||
There was a problem hiding this comment.
It was intentional for DiskQueue to not have first class knowledge of Message - that's why we had the shim in between the two.
|
@Dieterbe I appreciate the effort to clean things up. As per my two comments above, I don't think we would land this. If you want to get your feet wet with the codebase, might I suggest some of the |
|
i see. totally get DiskQueue should not deal with message concepts, makes total sense. the main thing i wanted to achieve is make Guid public so that i could embed nsqd into my app publish messages through the go api instead of tcp, the only thing seemingly needed for that is the Guid stuff. but i read your comment on the mailing list that you're not a big fan approach, so maybe i ishould just deal with it and use the network api. (through the go-nsq library) though i still think direct calls are a lot more robust. |
It's really just that we don't want to have the burden of publicly supporting the in-process API. Besides, I think it would result in a deployment that is too tightly coupled. NOTE: You can still generate your own message IDs, without any of the changes in this PR. Going to close this. Thanks again! |
|
thank you Matt, for the nice work :) |
what do we think about this?
note: currently causes
go testto fail. haven't figured it out yet, wanted to check first if the general idea looks good.