remove flumeview-query/links fork

[dominictarr]

I am very disapointed that the contents of the lib folder is copy pasted from flumeview-query.
Why didn't you make a PR? copying my code might save you time one day, but it means you are now maintaining my code, and since you didn't even post an issue, I didn't even know where doing this until I read the code because of the forks discussion. You are just creating more work for yourself and making my work less effective!

[mmckegg]

It was always my intention to do these changes as a PR, but I couldn't figure out an elegant way to merge this into the existing flumeview-query module. Besides the code is simple enough. It is mostly just routing options into place. Could be simplified right down if it was just merged into index.js

I'm really not interested in bikeshedding an API so I don't want to discuss how to implement this as options in flumeview-query, but if you really want to remove this duplicate code, then go ahead and make a PR!

Here's what would need to be added to flumeview-query

• an unbox option (pass in a function to run against log)
• return the original item instead of just the indexed attributes

[dominictarr]

At the very least, you should post an issue to let me know you are doing this.
If my api doesn't meet your needs, that is something I need to know!

why does it return the original item?

[mmckegg]

@dominictarr

why does it return the original item?

This module is used to retrieve related messages. If it didn't return the original item, the client code would need to perform a second lookup to get the actual item. Why not just return it as part of the index?

It could be an option like {values: true} when calling links.read

---

How do you think we should implement the unbox functionality? Are you happy with passing in an option to the constructor?