Lighthouse 2 planning

[Zaprit]

Here I'd like to have some discussion about what we want to do with Lighthouse 2, and what we want to definately do differantly compared to ProjectLighthouse.

Some things to consider:

• What programming language?
• How do we want to do our data layer (what kind of DB, access layer, etc.)
• How do we want to structure our web stack (frontend and backend).
• Packaging, I feel like Lighthouse 1 could really have done with some decent packaging, as it made setting up a server difficult.
• How can we do better with regards to CI/CD.
• Interoperabillity, i.e how can we make Lighthouse 2 more compatible with other LBP servers, rather than living as hermits forever.

[Zaprit]

Another thing, abstraction. Lighthouse 2 needs to be more modular, lest we end up in development hell again.

[sudokoko]

Here are my opinions for this.

--

What programming language?

I feel like most of our development team is rather familiar with C# for the most part. It would probably be in our best interest to continue using C# to prevent an unnecessary learning curve.

How do we want to do our data layer?

I think Postgres would be rather ideal for our usage case. A few reasons I can think of would be partial indexing, as well as it being generally better for larger databases and bigger I/O operations.

How do we want to structure our web stack?

I believe we should continue to keep the front and back end as modular as possible, and remove the need for a shared ProjectLighthouse class library. How we do this, I'm unsure of yet. But this would be a great benefit.

Packaging?

We could design the project in a way that it can be built into a self contained, single file binary that we can host on our own PPA/repo-equivalent source, so an administrator could simply run apt-get install lighthouse and have a fully functioning server.

How can we do better with regards to CI/CD?

Our current CI/CD flow is a mess in my opinion. We should consider chunking up operations into separate jobs so we can better observe the flow at a glance and see where exact failure points are. We could also benefit from adding a linter to the CI/CD flow starting out to maintain code styling. We could also add something like Codecov for test coverage results.

Interoperabillity, i.e how can we make Lighthouse 2 more compatible with other LBP servers?

The Bunkum project has established a few "standards" per-se for referencing LittleBigPlanet server information, etc. A good example would be AutoDiscover. Another example would be the RPC information API.

--

If you've got any concerns or questions regarding what I've suggested please feel free to let me know :)

[Zaprit]

Something else to add to the list of things to do, is we need better monitoring and statistics, so we can spot issues before they become a problem

[sudokoko]

https://sentry.io/

[na-stewart]

Very interested in contributing to the beginning stages of this as summer approaches. I agree with postgres for the database, I think the actual level savedata could be configured to run in a CDN or saved on the server directly. This would make scaling easier if any one particular server got very popular.

[na-stewart]

I also was beginning to work on something to streamline the LBP emulation setup process as that is somewhat comprehensive for non-technical users.

[m88youngling]

Thank you for your interest!

[Ezoiar]

We need the Cat Button.

[kysoy]

Make the website more stylized, the way it looks right now isn't appealing in any way and just looks corporate.

also pls make it stop logging me out daily

[Ezoiar]

this

[Nariko0]

use this as the logo

[vilijur]

finally some good designs