Assets Library Proposal: Request for Clarifications

Hello Everyone, I’m preparing my GSoC proposal for the Assets Library project and want to ensure it aligns with the team’s vision. Having reviewed the codebase and previous community discussions about asset storage, I have a few targeted questions.

Could you clarify:

  • Should the library UI mirror the existing AssetListBox design, or would a new responsive panel (e.g., with scrollbars for large asset sets) be preferable?
  • Would implementing shared assets require a GlobalAssetManager service in App Engine?
  • How does the current system handle asset storage, and would shared libraries need separate storage buckets/namespaces?
  • What validation is needed for user-uploaded assets (size limits, MIME types)?

Some proposal-related doubts:

  • Is this project a high priority for 2025, given its recurrence in last year’s ideas?
  • Should the proposal include a design/mockup, or is that iterative post-selection?
  • Are there specific milestones you’d recommend focusing on first (e.g., backend CRUD operations before UI integration)?
  • Any prerequisites or requirements I should focus on that are not mentioned specifically on the idea list? I am new to the project, is there any resource to study the project codebase?
  • Would you be open to reviewing my draft proposal via email before submission?

I understand you guys might be busy, and I truly appreciate any guidance you can share. Thanks for your time!

CC: @ewpatton @jis

In my opinion I think we would want to have a different view for user level assets. Internally in the data store, we have UserFileData and FileData, the former is used to currently store the user's signing key and the backpack whereas the latter is hierarchically under ProjectData and represents an individual file in a specific project. This would be similar to having all of your pictures in the "My Pictures" album on your computer but having to choose specific pictures to include in an app made in another IDE.

If we go with the UserFileData approach, I would expect it would be another route in either the UploadServlet/DownloadServlet or UserInfoService.

We can likely reuse the existing GCS bucket for the asset storage, but structuring it so we can change it later would be a helpful design.

There is existing logic for asset upload that we could refactor to cover this.

The list is chosen based on things we think would be useful to have.

Both typically. A starting point is good but we often refine projects as we build things out and learn more.

Probably user facing design will be most important. We will want to see what the UX flow is like.

Being able to build our code base and modify files in the client and server packages under the appengine directory are probably all you really need.

I have offered in the past to review proposals received in advance of the deadline. Because I'll be occupied on April 8th, any proposals will need to be available for me to review before April 7.

1 Like