Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

odysseus654
Copy link
Contributor

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:

  • All avatar and domain ownership challenges
  • Queries to FST files to see if they came from the marketplace
  • Permissions "can rez certified" and "can temprez certified"
  • The "Wallet" and "Marketplace" apps, along with the majority of the "Security" app
  • A context overlay of some kind showing the current marketplace status of any item
  • The "upload Avatar to Marketplace" tool
  • The scripting objects ContextOverlay and WalletScriptingInterface
  • 12 entity properties exclusively used for the marketplace (still kept in the protocol stream for compatibility, but unused)
  • Assignment Clients being paid for their work (related: the -wallet option on assignment-client)

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)

@two-one-five
Copy link
Contributor

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.

@odysseus654
Copy link
Contributor Author

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...

@odysseus654
Copy link
Contributor Author

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)

@two-one-five two-one-five added allow-build-upload Allows the upload of a build for non white-listed users rebuild rebuild through the GithubActions labels Aug 31, 2020
@two-one-five two-one-five added the scripting api change Change is made in the scripting API label Aug 31, 2020
@ctrlaltdavid ctrlaltdavid added the hifi migration Issues and PRs relating to migrating away from High Fidelity dependency. label Sep 3, 2020
Copy link
Contributor

@daleglass daleglass left a 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() {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this change?

Copy link
Contributor Author

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?

Copy link
Contributor

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());
Copy link
Contributor

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.

Copy link
Contributor Author

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);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

Copy link
Contributor Author

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.

@odysseus654
Copy link
Contributor Author

Have rebased & squished the commits in this PR. Will compile/smoketest as well as remove MixerAvatar.cpp

@odysseus654
Copy link
Contributor Author

Smoketested the interface and dropped the empty MixerAvatar.cpp file. Note that I have not yet done any testing of the server.

@two-one-five two-one-five added do not merge do not merge due to issues or pending updates CR Approved At least one code reviewer has approved the PR. labels Sep 13, 2020
@JulianGro
Copy link
Contributor

Could you get rid of the merge conflicts so I can build and test this?
I cannot view the conflict, so I have no idea how big of a change it might be.

@odysseus654
Copy link
Contributor Author

Rebased / squished the commits in this PR. Have compiled / smoketested to check for any obvious issues.

@JulianGro
Copy link
Contributor

@JulianGro
Copy link
Contributor

I haven't had any problems with this yet.

@ctrlaltdavid
Copy link
Collaborator

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.

@odysseus654
Copy link
Contributor Author

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).

@ctrlaltdavid
Copy link
Collaborator

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.

@odysseus654
Copy link
Contributor Author

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.

@odysseus654
Copy link
Contributor Author

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.

@daleglass
Copy link
Contributor

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?

@digisomni digisomni added the dormant This PR is on hold but has interest/use surrounding it. label Nov 6, 2021
@Penguin-Guru
Copy link

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.

@stale
Copy link

stale bot commented Jul 26, 2022

Hello! Is this still an issue?

@stale stale bot added the stale Issue / PR has not had activity label Jul 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
allow-build-upload Allows the upload of a build for non white-listed users CR Approved At least one code reviewer has approved the PR. do not merge do not merge due to issues or pending updates dormant This PR is on hold but has interest/use surrounding it. hifi migration Issues and PRs relating to migrating away from High Fidelity dependency. rebuild rebuild through the GithubActions scripting api change Change is made in the scripting API stale Issue / PR has not had activity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants