Team 5 Day One Material - rsanchez-wsu/jfiles GitHub Wiki

#Idea Tree

We are currently focused on how we could split up our teams so that we could focus on more specific ideas. Here are the broad team ideas we have developed:

  • Current Tasks
    • File API
      • Java's existing file class
        • May extend the file class and add functionality
          • This way we would only have to merge in any functionality we find that we need, with minimum editing. (+)
          • We could override methods to directly change their function very easily. (+)
          • We can override to disable any methods that are not going to be used would otherwise pose a security risk to the program. (+)
          • Overriding methods to can also cause confusion if other members expect a method to function a particular way, so documentation will be extremely important. (-)
          • Unless we do a major overhaul of the class, we may not have as much as control as creating a new class with a File field. (-)
        • May create new object with a File field
          • This may be easier to incorporate into an object we make for grouping file objects of this kind. (+)
          • With this route, we would know all functionality of the object. Only the methods in File we want the program to be able to use will be usable via this object. (+)
          • We would also have to create methods for handling all methods for all fields of the file object. (-)
        • May use as-is
          • Obviously the quickest option now, but may be hard to work around later. (+/-)
          • Will eliminate the need for an entire team to put more pressure on other teams. (+/-)
          • Most valid when considering the use of a class that only has static methods. (+/-) <--! I know there's a name for this, but for the life of me I can't think of it. Please correct me if you know of the word and clear this comment.>
      • `FileUtility` class idea
        • Can be used to supplement the functionality of file objects by adding static methods outside of the file class.
        • Can be used to create references to static things such as a users home directory. The variable can be loaded in during startup from config. May not be needed if we can look up system information for this, but may still be desired to create quick links to important pieces of system information.
      • How to save objects if necessary
        • Directly as objects
        • Via text information and parsing
        • A combination of objects and parsing
        • Via XML
        • How the project develops will determine how and what option is best. It may be that this entire subject is moot, but it is better to have our options listed now.
      • Important Methods and Fields:
        • `open( )`
          • Function: Opens the file with the default application for this file type.
          • Has the same issue as seen in the `FileUtility` class idea. Either we need a way to determine this from the system or set this via configs. Another option, is use system information as default (if possible) and use config information if it is there. This way, the user can determine a default in the config that is separate from the one in their OS. I can see this being useful for some one who wants to say use one browser to open images in an editor and another to open them in a viewer.
        • `openWith(Application app)`
          • Function: Opens the file with a selected application.
          • May want some way to check compatibility.
          • May want to use the pre-built file selector, or we could create a new one based from our actual project.
          • May want to search only for files with a particular extension (may be handled already in the file chooser).
        • `Tag[] tags`
          • Function: Lists tags that the user can assign to files.
          • Will tags be pre-determined or customizable?
          • Maybe a file can be used to store tag names. This creates a balance between
    • File Reader/Explorer API
      • Read-only mode
      • Authority modes or authorization
      • Creating new documents
      • Suggested Files/Folders?
      • Frequent Files/Folders?
      • Hiding Files
      • Set file Tags
      • OS Awareness
      • Other Utilities: <--! Someone start list then delete comment>
    • Implementation
      • CLI or GUI?
        • Suggestion: Use CLI now, but go ahead and build some GUIs for particular functions, such as new folder and the like.
      • XML Config Files loaded at startup
    • Client API
      • [Add specifics here.]
    • Server API
      • [Add specifics here.]
    • Database API
      • Will hold file objects and provide functionality for handling groups of files, such as folders.
      • May hold computer objects that store information on computers that can then be used by the Server API and Client API teams.
  • Future Tasks
    • Security API
      • Encryption types/ implementation <--!Someone list; delete comment when done.>
      • Encryptions inside of each other
        • Security or efficiency?
        • Configurability for preference?

    It is important to note that these ideas are currently focused on networking, since that is the subject we are tackling first. We also incorporated other teams ideas into this to make this as comprehensive as possible.

    #File API Specific

    From here, we focused on the File API idea, which is the subject our team wants to tackle.

    Java has a class built in called File that can be used to iterate through the files, each file could then have the information about each file to an XML file.<--!Either change "have" to "add" or "to an XML file" to "on an XML file">

    We have many options for how we organize data on files, and the team that receives this subject must determine which path they think is best.

    ##Three Ideas

    1. We will look into what base concept for the file we want to commit to (Java's File).
      • Summary: Though the idea of the wrapper is more secure, there are concerns regarding orverrid-ability of files methods in the wrapper.
      • We already knew that we could handle files one of three ways using the File class. We now know that, since we have to modify some of File's functionality, using File outright is not an option. This leaves extension and an object wrapper. We favor the wrapper because it is more controlled. By making a JFile object with a private File field, we can create a wrapper that limits the functionality of File to exactly what we want. This means JFile will be able to do everything we want it to without anything we don't. This makes this option more secure. The extension route, though appropriate since a more specific version of File is our intent, is less secure.
      • This means that any and all methods we want to use from File need to be passed down from the private object. Another thing that would be of concern is how we will modify File methods. We can run File methods in JFile methods, but may not be able to do something in the middle of the method, without overriding the method, which we can't do with a wrapper. One solution to this, though cumbersome, would be to create an inner-class that extends File and overrides the methods we need overridden. This is the biggest drawback.
    2. Further develop a list of methods for our File object and what functionality we will want it to have.
      • openAsExe()
        • This is in regards to the fact that "openWith(Application app)" inherently assumes the object is a file to be opened by another application, as opposed to being an application itself. This method should run the application on its own if it is an application and throw an error if it is not (of if there is some other error).
      • delete()
      • copy()
      • paste()
      • showProperties()
        • What properties? Can we get these from File?
      • createFile()
      • zipFolder()
        • For further down the road. This would be simple(r) in Linux, but should have functionality in all OSs if we include it.
      • unZipFolder()
        • For further down the road. This would be simple(r) in Linux, but should have functionality in all OSs if we include it.
      • getFileType()
        • This is necessary for checking whether a file is indeed a file, an executable, a folder, or something else, for use in other methods.
      • getURI()
      • setURL()
      • rename(String Name)
        • This will most likely be run in a GUI made by a team working on a GUI API. We could also remove the input parameter and make the method itself throw the user a GUI, but I prefer to keep the focus of each API separated.
      • getLastChanged()
        • For use in accounting.
      • getProperties()
        • A GUI for this is advisable.
      • move(Location location)
        • "Location" will be some TBD object. May be File. May be JFile.
      • getSize()
        • For use in determining if a drive has enough room when copying. May also be usable in other ways.
      • getLocation()
    3. Think about how we want to handle folders.
      • Can File be used to handle Folders?
      • If yes, we can extend JFile and bring in the methods on File necessary for managing a folder.
      • if no, we can create a folder object that can hold an "JFile[] contents", and build functionality for the object to be a folder.
      • Without reading into File more, there is little we can do for this. We need to know which route we are going to go down to do any further conceptual development.

    ##Other Things We Considered

    • We can pass authentication, authorization, and accounting methods into JFile (and if necessary JFolder) methods once those methods become available
    • We need to look into the class File and interface Runnable, as these will most likely be critical to our API.
    • In OS-aware methods, we discussed using the System object, though we need to read more into this before committing to this concept more. Additionally, we think it would be wise for there to be some initialization that loads this information at start so that it can be quickly accessible. For this, we suggest an object in memory. For further down the road, if we have time, we can create an object that just loads in the information from the system that we need into memory instead of using System, but that is a ways away.

    You'll never belive these 5 guidelines, Number four will surprise you!

    #End Notes

    Please note: This wiki does not overlook options that would otherwise be impractical. It's main purpose currently is to come up with and organize as many options as possible and contemplate what implications those options may have.

    • ⚠️ **GitHub.com Fallback** ⚠️