mugle-dev team mailing list archive

[Matt Giuca <728148@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

I don't think the current GameFile class is appropriate. Note that it
deals with java.io.File a lot -- not as a field (which would be very
wrong since we can't store a "File" in the database), but nonetheless, I
don't know if GAE will even let us use the java.io.File class, let alone
give us one. GAE does not have a file system (which is why we are using
blobs in the first place).

Think about the use cases for GameFile. They will basically be entirely
HTTP-based. MUGLE isn't going to use the files at all -- it is just
implementing a file-system-like interface on the blobstore, via HTTP.
The HTTP interface will basically be you can PUT files and you can GET
files, and that's it.

>From within the program, the PUT operation will basically come to us as
a javax.servlet.http.HttpServletRequest object
(http://download.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html).
You get the body via the HttpServletRequest.getInputStream() method,
which returns a java.io.InputStream object
(http://download.oracle.com/javase/1.4.2/docs/api/java/io/InputStream.html)
-- the same type as System.in. So the GameFile constructor should not
take a File, it should take an InputStream, and read the contents from
there, storing it into the blobstore. This will allow some higher-level
HTTP code to receive a PUT request, get the InputStream, and pass it to
GameFile.

>From within the program, the GET operation will basically require that
we fill in a javax.servlet.http.HttpServletResponse
(http://download.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html).
You can write to the body via the HttpServletResponse.getWriter()
method, which returns a java.io.PrintWriter object
(http://download.oracle.com/javase/1.4.2/docs/api/java/io/PrintWriter.html)
-- similar to the type of System.out, but not the same. So the
GameFile.getActualFile() method should not return a File, it should take
a PrintWriter as an argument, and write the contents to it. This will
allow some higher-level HTTP code to receive a GET request, get the
PrintWriter from the response, and pass it to GameFile.getActualFile()
to populate the response.

** Affects: mugle
     Importance: Medium
         Status: Triaged


** Tags: datastore filesystem

-- 
You received this bug notification because you are a member of MUGLE
Developers, which is subscribed to MUGLE.
https://bugs.launchpad.net/bugs/728148

Title:
  GameFile should not deal with File objects

Status in Melbourne University Game-based Learning Environment:
  Triaged

Bug description:
  I don't think the current GameFile class is appropriate. Note that it
  deals with java.io.File a lot -- not as a field (which would be very
  wrong since we can't store a "File" in the database), but nonetheless,
  I don't know if GAE will even let us use the java.io.File class, let
  alone give us one. GAE does not have a file system (which is why we
  are using blobs in the first place).

  Think about the use cases for GameFile. They will basically be
  entirely HTTP-based. MUGLE isn't going to use the files at all -- it
  is just implementing a file-system-like interface on the blobstore,
  via HTTP. The HTTP interface will basically be you can PUT files and
  you can GET files, and that's it.

  From within the program, the PUT operation will basically come to us
  as a javax.servlet.http.HttpServletRequest object
  (http://download.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html).
  You get the body via the HttpServletRequest.getInputStream() method,
  which returns a java.io.InputStream object
  (http://download.oracle.com/javase/1.4.2/docs/api/java/io/InputStream.html)
  -- the same type as System.in. So the GameFile constructor should not
  take a File, it should take an InputStream, and read the contents from
  there, storing it into the blobstore. This will allow some higher-
  level HTTP code to receive a PUT request, get the InputStream, and
  pass it to GameFile.

  From within the program, the GET operation will basically require that
  we fill in a javax.servlet.http.HttpServletResponse
  (http://download.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html).
  You can write to the body via the HttpServletResponse.getWriter()
  method, which returns a java.io.PrintWriter object
  (http://download.oracle.com/javase/1.4.2/docs/api/java/io/PrintWriter.html)
  -- similar to the type of System.out, but not the same. So the
  GameFile.getActualFile() method should not return a File, it should
  take a PrintWriter as an argument, and write the contents to it. This
  will allow some higher-level HTTP code to receive a GET request, get
  the PrintWriter from the response, and pass it to
  GameFile.getActualFile() to populate the response.