elliottmb / 486project Goto Github PK
View Code? Open in Web Editor NEWLicense: Other
License: Other
One of our first tasks is designing what layers of our application need to exist and how they should interact.
One common design idea is having Services which may or may not be running on different threads, that the main Application class keeps track of. These services would have synchronized methods for pushing and pulling data upon them. This may provide the easiest to implement architecture but has some SOC draw backs. (Need to getApplication().getSpecificService() a lot and make sure we're not holding onto access of anything.)
Other design ideas are having the core data living in a single container, with async tasks or runners that temporarily own a copy of the data to manipulate it. One issue here is checking ownership over time, especially with the database connection (since H2/Sqlite generally run embedded with minimal support for multiple connections unless you force it into server client mode)
Currently multiple clients can simultaneously be signed into the same user account.
No real downside other than a user experiencing differing ledgers over time if all instances aren't interconnected.
Possibly leave as is.
Ideally we should have a 'loading' type screen so that we can have it just spinning and saying "Connecting to Authority", so we can await the connection to the authority. Then once the connection comes through, the main thread would event trigger the connecting screen to transition to the login screen.
Also, it may be nice to have a "Retry" button that'll be able to be displayed if the connection to the central authority fails after x attempts.
Currently datagrams that need a parent are pushed into a waiting queue, but that queue is never processed. There are steps which need to be laid out in that area, which haven't fully been considered.
Essentially, an item in the "waiting" queue has had a ParentsOfRequest or AncestorsOfRequest dispatched. At this time, the former is the only one dispatched as the criteria for switching to the latter hasn't been formalized.
Once in the waiting queue, there is an AtomicLong attached to check for how long it's been in the queue. (Incremented on access)
In the waiting queue, when accessed, we need to check if we have the parents in the database at this time. If we have, we can move to the ready queue. If not, we need to check if the parents are in the toProcess or waiting queues. If they are, pop back on the waiting queue.
Essentially, when a chain of ParentsOfRequests have been made and co-exist in the waiting queue, we should consider doing an AncestorsOfRequest for the oldest generation. I believe a threshold of three generations may be the point to do this, as there would only be at most 4 grand parents to request ancestors of.
To check if we're in this state, instead of naively requesting parentsof as we currently are within the toProcess step, we should check if the current datagram is the parent of a datagram in the waiting queue, and if that child is a parent of datagram also in the waiting queue. If this is true, send a AncestorsOfRequest, otherwise ParentsOfRequest.
At this time, if the connection to the authority is lost, an exception is simply thrown and we do not handle it. There are a few routes to go, such as reattempting automatically, or showing a notice to the user in the UI and requesting that they reconnect.
In either case, the user is no longer "logged in" and this needs to be conveyed and we need to prevent message creation in the ui. (Disable submitting and have a notice.)
Due to the overpowering nature of Spring's dependency injection and containerization, the current project structure allows only one class using SpringApplication to exist. Therefore we need the following subprojects
This also entails communicating this information both to the UI, possibly through an ApplicationEvent that the ChatController listens for, and to the ClientManager to establish any not already established connections.
Continuation of #11
To facilitate pretty display of records, we need to actually know the username association with the UUID stored locally. A simple method for doing this is to provide the UUID -> Username pairing to authorized clients on login. The client then can store that in a map and reference it as needed for display.
This is a three stage issue. First stage is to be handled by Jake, implementing the message class and message sending on the authority side. Second stages I'll handle with implementing the map and exposing it safely. Third stage will be Ryan's integration with the UI.
Currently, only messages that are "submitted" are shown, and are shown before validation.
As we are using Apache Mina, we can take full advantage of Object serialization provided by Java or any custom serializer. As such, we can construct each network message (NM) or request and response as independent Classes and use the type system to guarantee safety.
At this time we've identified the following use cases / NM between clients
And the following for between the client and authority
Possible future messages that we may need, but not confirmed at this time:
Currently disabled, because it doesn't work properly. Despite the init(null, null, null) apparently grabbing default implementations as per the javadocs, it appears that it creates a non-usable state.
Currently when a client's consumer connects to another client's producer, the second client's consumer should connect to the first clients producer in kind, to create a query loop. This is currently not implemented, so communication is one sided. Some progress has been laid out for this, but I'm thinking the handler method currently in development may not be ideal, but instead an exchanging of peer information may work better upon connection.
For testing, we should have a method of connecting to a known ip and port. This will allow us to get client - client working while the authority components aren't finished
Currently, once you're logged in, there's no means to log back out.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.