Session transfer JSON format

[coderbyheart]

For importing sessions to be optimized and to export the result the information needs to be transferred via JSON.

Proposal

This JSON format has been proposed by @McWizard

• Input
• Output

Background

Als Übersicht auch eine Konsolen-Ausgabe, damit man das JSON leichter versteht. Hier eine kleine Legende:

-------- Overflow #1 [Seats(-100)]--------
12 Uhr:Java for nerds -- [Olga]                           NEED:Beamer Seats(10) FD: 12WD: (50) - 10 11 13  -- COST: 1320

Die Session von Olga ist für 12 Uhr eingeplant und sie braucht einen Beamer. Das entspricht auch dem FixedDate (FD) von 12 Uhr. Daneben hat sie noch Wünsche (WD) angegeben (was bei FixedDate Blödsinn
ist). Die Wünsche waren entweder 10,11 oder 13 Uhr mit einer Strafe von 50 bei nichterfüllen. Die Kosten für diese Session waren 1320, was ziemlich viel ist, was aber klar ist, denn wenn man sich
anschaut wo sie ist, sieht man das sie im Overflow-Raum ist, also keinen eigenen Raum bekommen hat. (Waren halt auch nur 10 Interessenten da).

Zur Eingabe:
Man beachte so Dinge wie "FixedDate" und "WishDates", die sind Optional (sind aber in den Testdaten enthalten).

Jede Session kann angeben, wie schlimm die (nicht-)Erfüllung einzelner Kriterien ist:

Für Kriterien, die mit Zahlen beschrieben werden (sowas wie Sitze):
"unsatisfiedPenalty": 1000, --> Das Kriterium gibt es in dem Raum gar nicht (haben wir aktuell nicht, da das einzige Kriterium "Seats" ist und jeder Raum das hat.
"notQuietsatisfiedPenalty": 20, --> Wenn der Wunsch nicht ganz erfüllt werden kann, gibt es diese Strafe einmalig
"differencePenaltyMod": 10, --> Und dann noch für jeden Punkt Differenz zwischen Wunsch und Wirklichkeit diesen Wert (10 pro Seat)
"positiveDifferencePenaltyMod": -1 --> Wird das Kriterium übererfüllt (also größerer Raum für kleinere Session) dann gibt es ein paar Bonuspunkte (1 pro Seat)

Für Kriterien, die entweder da sind oder nicht (z.B. Beamer):
"penalty": 200 --> Kein Beamer

Daneben gibt es bei jedem Uhrzeit-Wunsch noch ein penalty für dessen Nichterfüllung.

Und globale Penalties (am Ende der Eingabe zu finden):
"string": "NOT_MATCHING_FIXED_DATE", --> Wenn das FixedDate nicht eingehalten werden kann
"int": 10000

"string": "NO_ROOM_FOUND_AT_ALL", --> Wenn eine Session keinen Raum bekommen hat
"int": 10000

"string": "SAME_SPEAKER_TWICE_ON_A_DATE", --> Wenn ein Speaker zweimal zur gleichen Uhrzeit auftreten müsste (Das ist natürlich schlimm, daher hohe Strafe!)
"int": 1000000

--> Über die Höhe der Strafen müssen wir halt mal reden und so fragen klären wir:
Was ist schlimmer? 10 Plätze zu wenig im Saal oder keinen Beamer?
Geben wir den Leuten die Möglichkeit ihre Wunsch-Daten auch mit einer Stärke zu definieren? Also so was wie: Ich würde gerne um 8 vs Ich bin um 8 noch nicht da?
...

Zur Ausgabe:
Bei der Ausgabe wurden autmatisch Overflow-Räume hinzugefügt, weil es mehr Sessions als Räume waren.
Daneben gibt es die "OccuredPenalties" (entspricht dem "cost" von der Konsole). Ein kleiner Wert bedeutet, dass die Session sich dort wohl fühlt, große Werte deuten auf Unschönheiten (zu kleiner Raum, fehlender Beamer, nicht erfüllter Zeitwunsch) hin .

[coderbyheart]

I don't like your proposal. You are adding language specific terms and structure which might be ok, if you are transferring data within your application, but we have to generate the input in a different systems.

To generate things like

"string": "Beamer",
"sessionOpt.entities.features.BooleanFeature": {
    "name": "Beamer"
}

will be a nightmare.

[coderbyheart]

Having said that … Can you imagine using a more generic JSON format @McWizard? If so, do you want to design it, or should I give it a shot?

[McWizard]

Well, the creation of the proposed format is the result of throwing my object-structure at xstream. That format is no more effort than 2 lines of code:

XStream xstream = new XStream(new JettisonMappedXmlDriver());
request = (Request)xstream.fromXML(new File("input.json"));

If we define a new format from scratch, I'll have to write some kind of parser to read it which is totally possible but we'll have a writer on your side and a parser on mine.

I'd only go that route if you really have problems creating the above format.
The good thing with the proposed format is that it's very generic. You can add features at will. I don't need to define them in the application...

[coderbyheart]

How is
"sessionOpt.entities.features.BooleanFlag"
generic?

It really smells to have this kind of implementation detail in the exchange. I have to write a parser anyway so there is nothing to gain on my side. And it would be a format that also is used by the webapp ...

[McWizard]

Oh if that's the only thing: How about something like this:

          "preRequisites": [
            {
              "entry": [
                {
                  "string": "Beamer",
                  "booleanPreRequisite": {
                    "name": "Beamer",
                    "penalty": 200
                  }
                },
                {
                  "string": "Seats",
                  "intPreRequisite": {
                    "size": 80,
                    "name": "Seats",
                    "unsatisfiedPenalty": 1000,
                    "notQuietsatisfiedPenalty": 20,
                    "differencePenaltyMod": 10,
                    "positiveDifferencePenaltyMod": -1
                  }
                }
              ]
            }
          ],
          "isOverflow": false
        },

Would that be ok for you?

[McWizard]

And what I meant with generic is that if you plan to have another metric than Seats, let's say Number of Network-Ports, you can just add that to the rooms as features and to the sessions as preRequisites and you're set. That's why there's not a simple field called "Seats" in the interface...

[coderbyheart]

Ok, let's use the JSON as mentioned here