Move working image handling from Spritely class to a Session format

[ca2longoria]

Summary

Originally, Spritely held the current working image and related data as variables/properties/attributes of its own. In light of the eventual move to multiple running sessions, I created a Session class and added some go-between logic so as to avoid changing too many things at once. Unfortunately, my changes exceeded my capacity to recall what I was doing, and I ended up with a confused garble of mess (still works, though). Now this must be fixed, while maintaining Session usage

---

Concrete Requirements

• [x] - Session class handled by an appropriate parent
• [x] - proper behavior distributed between Spritely, Server, and Session classes
• [x] - coherence to some overlaying organizational structure

---

Depends On

• [x] - Issue #8 (refer to noted Issue reference in the comments) <- some overlaying organizational structure

[ca2longoria]

The three classes in question are:

• Spritely
• Server
• Session

Before, Spritely stored the single working- BufferedImage and File objects. Server would call on its Spritely instance parent (Spritely.this) to get these objects when necessary.

Now, however, there is the Session class, which has taken responsibility over the ownership of workingImage and workingImageFile, but which is also an instanced subclass of Spritely. Yet, Session still calls on its Spritely parent to pull those image objects.

[ca2longoria]

First, then, let's mock up these objects' current relations to each other.

• Spritely
  • Session
  • ImageSet
    • workingImage
    • workingImageFile
  • Server

These are needed by Server... workingImage -> Server workingImageFile -> Server

But Server has to go through... Server <- Spritely <- Session

Additionally, the current Session (there's only one current session object right now, have yet to even move to a multiple session format) is not initialized during Spritely initialization, nor Server initialization, but during the handling of the :heretakethis REST call.

How... obscure...

So we run into a problem here. Where or when should Session be initialized, and where or when should it be assigned the Image file in question?

Oh right, and there's another thing. Inside of Session is an ImageSet object that stores the actual files, which Spritely directly references in its getImageFile method. (Little outline, above, has been updated)

[ca2longoria]

What have I done!?

Oh well, let's get to work.

[ca2longoria]

As noted by GitHub, Issue concerning overlaying organizational structure is #8.

[ca2longoria]

Okay, we're abiding by this:

[ca2longoria]

There's still some debate on the preferred return types of the Spritely -> SpritelyServerPlugin step. At present, they are Map<String,Object>, but really, that was intended for the SpritelyServerPlugin -> Sever step, except that that was decided on the spot to return as a NanoHTTPD.Response.

[ca2longoria]

That can be a new Refactoring issue. One moment...