The underlying concept behind Team 5's File API is relatively simple: Use the other back-end modules to create an interface through which users can easily manipulate files. This creates a way to merge front and back ends. The File API shall implement all networking, file management, security, threading, and database management code made by other teams. Ideally, the objective is to have any team creating a front-end, be it a GUI or CLI for browsing/managing files or some program that happens to need to use files (such as, say a video game), be able to operate exclusively from this interface. This makes the system slightly modular by separating the front end from the back and definitely emphasizes flexibility.

Making sure that this code works, ensures that the overall project's back-end is functioning. That is to say, all modules made by all other teams must be functioning for the File API to be functioning, so if the File API is functioning, all things making it up must be functioning. When testing the File API, the Team 5 must take great care when an issue IS found. This is because they will have to figure out whether the issue is their code or the code of the team whose module the issue is in. Is it Team 5 not using the code correctly, or is there actually an issue in the other team's code?

Team 5 shall face many challenges in getting their code to work. One is communicating with teams, constantly learning other teams' code for implementation in the File API for implementation in the front-end. This is a lot of ground to cover, and covers a wide variety of materials.

Additionally, it will be difficult for Team 5 to ensure that all of the other teams are independent of each other. If one team needs code from another team for their module to work outside of the overall project, this team will have a dependency that cannot be resolved by Team 5. For the sake of keeping the system functioning, Team 5 must allow for such situations.

Balancing so many things is the greatest challenge though. Ensuring the system is as modular as possible, while still ensuring that they don't halt all progress in order to achieve it. Likewise, the same can be said for flexibility. Again, the same can be said for balancing the development and/or fixing of concepts and code.

The JFile Manager (JFM) is the primary focus of the project. It is designed to take all the back-end APIs, which will include networking, security (authentication, authorization, and accounting), configuration, initialization, threading, and file management, and build an easy to use middle-ware for use by front-end developers, such a people who are designing a GUI or CLI for use with this system. That is to say, it is expected that a programmer should be able to get all of the back-end functionality they need through this class.

This also makes it possible to use the middle to back portions of this program in another program. For example, if someone wanted to make a video game and needed a way for transferring files efficiently, they could use the JFM inside of their game.

The objective is for the end-user to use this class to take all the back-end APIs and use what they have to create easy-to-use methods, such as cut, copy, and paste. This is so that the end-users (either UI developers or someone who is embedding this in a larger program) have to do as little thinking as possible, freeing them up to focus more on their work. These methods shall be able to handle all of the networking, security, threading, and file management necessary, with as little input from the thing using the API as possible.

In addition to having the basic functions you would expect a file browser to have, such as cut, copy, and paste, this class shall have functionality for managing anything and everything a file browser would need. This includes things such as a clipboard and working directory. An end-user should be able to work entirely from this file, without any need to access any lower-level classes.

JFile is simply a class wrapping around a File object with more controlled functionality. This is done 1) to ensure that the object we are using is a bean and 2) to constrict the functionality of the File class by passing to JFile exactly what methods we want. The second part is done to ensure that we know exactly what JFile can and cannot do for heightened control and security.

Ideally, methods by networking APIs will handle the transference of the actual file contents, and JFile will be used more for metadata, such as file sizes and types. This will be most useful to the end-users of our API, and will be at the heart of many methods in JFileManager for getting this information, such a getType().

Hopefully, this will be implemented in such a way that the end-users can get the metadata without having to get the entire file. This creates difficulties since the file may not be on the client system to get the information. This can be solved one of three ways.

1. We can set up the system to recreate the File so that it points to the file on the host machine, thus getting the information from the source.
2. We can have a list of fields that auto-populate when the JFile is made so that this information can be available without the actual File, meaning that the file can be made transient.
3. We can have an object that holds all of the metadata and send that over, independent of the file itself.

We have not yet solved this issue.