New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop all dependencies on marketplace and wallet #666
base: master
Are you sure you want to change the base?
Conversation
ContextOverlay may or may not have been useful for security reasons? We should look into that to ensure there's not some usefulness to having something like that regardless. |
Yah that was a bit confusing to me too. Everything I saw had it keyed to ownership challenges for objects though, which was square in the crosshairs of this PR. Once I dropped those there was basically nothing left. I don't really know the value of empty containers at this point. Heck I think I may have left an empty .cpp file in this project after stripping out all the code... |
MixerAvatar.cpp likely can be deleted as well. MixerAvatar.h is still in use and appears to have value (even though 90% of it has been removed) |
The following links are available: build (macOS-latest, full) build (ubuntu-18.04, full)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, this is a lot to review, but given that it's mostly deletion if that goes wrong it should just fail to compile.
The actual changes made make sense to me though I do have a few nitpicks.
@@ -21,73 +21,24 @@ class ResourceRequest; | |||
class MixerAvatar : public AvatarData { | |||
Q_OBJECT | |||
public: | |||
MixerAvatar(); | |||
inline MixerAvatar() {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The entire contents of the MixerAvatar() constructor has been removed (and the .cpp file can likely be deleted as it's pretty empty). At this point it's an empty constructor. Alternative suggestions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mm, fair enough
APPEND_ENTITY_PROPERTY(PROP_ITEM_ARTIST, QString()); | ||
APPEND_ENTITY_PROPERTY(PROP_ITEM_LICENSE, QString()); | ||
APPEND_ENTITY_PROPERTY(PROP_LIMITED_RUN, quint32(-1)); | ||
APPEND_ENTITY_PROPERTY(PROP_MARKETPLACE_ID, QString()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe remove this one and those below? Name, description, categories, artist, license are pretty much certain to come handy in the future, but the rest look like hifi marketplace specific values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These properties are specific to the marketplace. I've done this so as to not break protocol until we're ready to, but if we keep them in this PR a later PR would likely drop these lines.
SKIP_ENTITY_PROPERTY(PROP_ITEM_ARTIST, QString); | ||
SKIP_ENTITY_PROPERTY(PROP_ITEM_LICENSE, QString); | ||
SKIP_ENTITY_PROPERTY(PROP_LIMITED_RUN, quint32); | ||
SKIP_ENTITY_PROPERTY(PROP_MARKETPLACE_ID, QString); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These properties are specific to the marketplace. I've done this so as to not break protocol until we're ready to, but if we keep them in this PR a later PR would likely drop these lines.
c26bec3
to
14bf816
Compare
Have rebased & squished the commits in this PR. Will compile/smoketest as well as remove MixerAvatar.cpp |
Smoketested the interface and dropped the empty MixerAvatar.cpp file. Note that I have not yet done any testing of the server. |
The following links are available:
build (windows-latest, full) build (macOS-latest, full) |
Could you get rid of the merge conflicts so I can build and test this? |
b9dbda9
to
3a4051b
Compare
Rebased / squished the commits in this PR. Have compiled / smoketested to check for any obvious issues. |
The following links are available: build (ubuntu-18.04, full)
build (windows-latest, full) |
Building works fine at the very least https://appimage.moto9000.moe/experimental/PR666/Vircadia-x86_64_PR666_3a4051b.AppImage |
I haven't had any problems with this yet. |
I think it would be better, as a first step, to disable items (e.g., don't show UI and/or comment out code) rather than a wholesale deletion of code - some of which may prove useful in the future (either as actual code or implementation hints) should we want to address similar functionality. Some code might be able to be removed after considering it, piece by piece. |
This deletion approach was done as it tends to be a bright-line describing all the code in the system that depends on the wallet in some form. Commenting out code can be a fine line between keeping code that may be useful in the system and keeping significant junk in the codebase that will never be used in the future. I do recognize the amount of loss that is involved in this patch though; a lot of the deletions I've made represented unrealized potential that I would really have liked to have seen happen. If some of this code has value to be kept in the system then yah let's keep it in (potentially commented out). Such decisions would have to be intentional though; the code is linked together enough that cauterizing parts of it out would take a bit of effort. I would not be against somehow breaking this PR up into smaller sub-PRs (and smaller decisions on what to drop). |
A series of smaller PRs, each focused on a particular area, may well be better. Even if, combined, they all end up removing the same code, at least we'll have merge commits in effect documenting code points likely to be involved if we want to re-enable or implement some particular feature at some later date. |
No major objections, PR #667 was originally part of this patch too. Would like to keep this PR open until a final decision is made on the whole (or the remaining) though. |
Although breaking this up into smaller pieces would likely cause some extra work to be needed depending on the amount of effort required to cauterize the linkages. I wouldn't mind suggestions. |
Dev meeting: it could be interesting to review why the merge is failing here -- this is code to remove, so why are changes being made that affect it? |
3a4051b
to
3dbaaf9
Compare
The following links are available: build (macOS-latest, full) build (ubuntu-18.04, full)
build (ubuntu-18.04, android)
build (windows-latest, full) |
3dbaaf9
to
97d2dc5
Compare
The following links are available: build (ubuntu-18.04, full)
build (macOS-latest, full) build (windows-latest, full) |
Whether it's broken up for removal or not, I think it's good to remove since it's not being used. If you think it might be useful to implement something in the future, you could then open a new PR adding those parts back in. That might be more subject to merge issues but I think there is practical value in streamlining the code base so it is more intuitive to new contributors. Hopefully this would also speed up the build process a bit. I think there has been some talk of implementing hypothetical market/commerce functionality purely as a tablet application, or perhaps using a server-side plug-in or module, rather than building it into the application code. Correct me if I'm wrong. |
97d2dc5
to
822a098
Compare
The following links are available:
build (windows-latest, full) build (macOS-10.15, full) build (macOS-10.15, client) |
Hello! Is this still an issue? |
This PR attempts to drop all references to the High Fidelity marketplace and wallet. Some effort has been made to prevent this from being a protocol-break (although there's a fair number of enums and entity packet content that could be pruned out once this is landed).
Going over the commits, things this thing removes:
Note that I did pick up on an apparent typo in AssignmentClientApp that on its surface appears to effectively disable the -a and -p options; I'm sorely tempted to break this up into its own patch for independent review (it must stay as part of this patch as well though)