Timetable Spec - Githubissues

karthikb351 commented 9 years ago

The timetable format is a basic 2D matrix of all the slots with the class numbers filled in at the appropriate places. This was a lazy approach and made so we could make client apps quicker. There are several problems with this approach:

It is upto the client to understand contagious sections of same classnumbers and mark them as a single class.
We have separate lookup times for the matrixes if the class is a theory or lab subject
All timings for a class are calculated and rendered client-side.
Not extensible. New slots/timings can't be incorporated without updating the client apps
Proposed Solution

Eliminate the timetable model altogether. Move class timings into readable formats within the course model. All time-lookups and logic is handled by the server, and only ready-to-consume data is sent to the client.

aneesh-neelam commented 9 years ago

And how do you propose we format the data?

Also, should I remove the existing timetable data? Or let it be?

aneesh-neelam commented 9 years ago

@karthikb351: Do you expect this for the immediate release or a later date?

VinayGupta23 commented 9 years ago

If I understand correctly, Suggested by the proposed solution is to move time-table data into the course model, (say for example as a list of [Day, Time] pairs for each course data that is sent).

While this provides a straightforward way to know "WHEN do I have classes for this PARTICULAR SUBJECT?", client-side computation is still required to know "WHAT classes I have on this PARTICULAR DAY?".

In other words, sending timetables "course-wise", requires the client to compute for "day-wise", and vice versa (as it is now).

............. Following on, this means it would require the client to make his own array (or matrix) to store the list of classes for each day, by iterating through all the data.

Then perhaps so does it not make the proposed model effectively equivalent to the current model being used?

karthikb351 commented 9 years ago

Since an API v2 is on the roadmap, let's move it to that. Legacy can remain where it is, everything in v2 is new.

{
    "courses": [
    {
        "title": "Database Design",
        "code": "CSE302",
        "timings": [
        {
            "recurring": true,
            "start_time": "0800", 
            "end_time": "0850",
            "day": 0 
        },
        {
            "recurring": true,
            "start_time": "1500",
            "end_time": "1550",
            "day": 0 
        }
        ]
    }
    ]
}

karthikb351 commented 9 years ago

@VinayGupta23 No not entirely true. The logic for "What class is when" is trivial, doesn't matter if you look at it day-wise or week-wise. This concept of a matrix is what is redundant.

Other than our the human-readable visual representation of what a week looks like, there is no need for a client to have a 'matrix'. It just needs to know the times of things.

The main issue issue is the way we compute these timings, namely, cross checking the slot matrix with a map of what time is what slot. And this varies of theory and lab subjects. And becomes a little more cumbersome when there are continuous lab slots(we need the start time from the first slot and the end time from the last slot)

None of the logic of finding the time for a class should reside on the client. That's the server's job.

karthikb351 commented 9 years ago

It's jugaad all around. Like this for example.

Calculating slots - https://github.com/saurabhsjoshi/VITacademics-for-Android/blob/lollipop/vitinfo2/src/main/java/com/karthikb351/vitinfo2/objects/TimeTableFiles/TimeTable.java Calculating times - https://github.com/saurabhsjoshi/VITacademics-for-Android/blob/lollipop/vitinfo2/src/main/java/com/karthikb351/vitinfo2/objects/TimeTableFiles/TTSlot.java

VinayGupta23 commented 9 years ago

Hmm... Yeah that's true. I didn't realize how miserable the general timetable has become especially after the introduction of Saturday labs and H and K slots. Looking at the URLs showing calculations, I see your point. It IS messed up due to the timings not being "uniform".

............. P.S. On a rather irrelevant note, I feel it is possible to implement some logic with fewer lines of code to calculate the timings (at least for theory) instead of hard coding all the values, since we retrieve (have) the 2-D matrix directly after scraping. But yes, it shouldn't be the clients job, I agree.

karthikb351 commented 9 years ago

@VinayGupta23 It's a long pending fix. If you want to take a crack at implementing this in node, go right ahead.

VinayGupta23 commented 9 years ago

Well this is one way to do it, that also includes

H, K slots (theory and lab as well)
Saturday labs. I know servers are not supposed to handle computation in general for excuse me if this novice. The following is in C#, its pretty straightforward so can be converted to node easily.

Code


// Assumed structure for Timing
struct Timing
    {
        string Start;
        string End;
        int Day;
    }

        Timing GetTheoryTiming(int rowIndex, int colIndex)
        {
            Timing timing = new Timing();

            if (colIndex >= 12) // H and K slots.
                colIndex--;     // To work around the "gap" in the theory timings as per general timetable.
            int startHour = (colIndex + 8) * 100;

            timing.Start = GetTimeString(startHour);
            timing.End = GetTimeString(AddMinutes(startHour, 50));
            timing.Day = rowIndex;

            return timing;
        }

        // There are labs spanning 3 slots as well, hence the third parameter.
        Timing GetLabTiming(int rowIndex, int colStartIndex, int span)
        {
            Timing timing = new Timing();
            int startTime, endTime;

            startTime = AddMinutes(800, CalculateOffset(colStartIndex));
            endTime = AddMinutes(800, CalculateOffset(colStartIndex + span - 1) + 50);

            timing.Start = GetTimeString(startTime);
            timing.End = GetTimeString(endTime);
            timing.Day = rowIndex;

            return timing;
        }

        int CalculateOffset(int colIndex)
        {
            int offset = 0, i = 0;
            while (i < colIndex)
            {
                if ((i >= 3 && i <= 5 && colIndex <= 5)
                    || (i >= 9 && colIndex >= 10))
                    offset += 50;
                else
                    offset += 60;
                i++;
            }
            return offset;
        }

        int AddMinutes(int time, int mins)
        {
            int totalMins = time % 100 + mins;
            return ((time / 100 + totalMins / 60) * 100) + totalMins % 60;
        }

        string GetTimeString(int time)
        {
            return time.ToString().PadLeft(4, '0');
        }

P.S. All indexes are zero-based.

Then, this is one way by which the parser/scraper can assign timings to every course:

foreach row in Timetable_Matrix
foreach column in Timetable_Matrix
select Course object where CourseCode matches current cell's CourseCode.
if theory type, add to timings list, GetTheoryTiming(row, column)
if lab type, get number of recurring slots with same lab. Then add to timings list, GetLabTiming(row, column, span)
end loop

Sample Results

// Monday, 4th slot lab (noon)
GetLabTimings(0, 4, 2);
// Result:
// timing.Start = "1150"
// timing.End = "1330"
// timing.Day = 0
// Friday, last lab session (night)
GetLabTimings(4, 12, 2)
// Result:
// timing.Start = "1930"
// timing.End = "2110"

This will also work if suddenly VIT decides to add Saturday night labs as well. Let me know if its any good... Thank you.

aneesh-neelam commented 9 years ago

It's actually very good. Damn neat.

However, I have something else in mind. I want to get timings when parsing timetable itself.

VinayGupta23 commented 9 years ago

Hmm well code logic could be possible workarounds for apps using the legacy apis I suppose.

@aneesh-neelam Thank you. Well THAT would be the neatest thing!

karthikb351 commented 9 years ago

No legacy support needed. We are building this alongside the older api, and then the client apps will switch over.

This is an opportunity to rethink it from the ground up.

aneesh-neelam commented 9 years ago

@VinayGupta23: You are building the Windows app from scratch right now, you shouldn't need to support the Legacy APIs.

VinayGupta23 commented 9 years ago

Of course, I get that... Sorry if my words were misleading or non-constructive, I was simply making a statement. I did not mean at all that the legacy be modified.

@karthikb351 Migration to newer APIs as you said is of course the final goal... Yeah true.

@aneesh-neelam Um no I wasn't planning on anything like that either.

Sent from my Windows Phone

From: Karthik Balakrishnanmailto:notifications@github.com Sent: ‎13-‎02-‎2015 16:58 To: aneesh-neelam/VITacademicsmailto:VITacademics@noreply.github.com Cc: Vinay Guptamailto:vinay.23.gupta@outlook.com Subject: Re: [VITacademics] Timetable Spec (#48)

No legacy support needed. We are building this alongside the older api, and then the client apps will switch over.

This is an opportunity to rethink it from the ground up.

Reply to this email directly or view it on GitHub: https://github.com/aneesh-neelam/VITacademics/issues/48#issuecomment-74240384

aneesh-neelam commented 9 years ago

This is done now, check latest development branch.

All timings are in UTC.

aneesh-neelam / VITacademics

Timetable Spec #48

Proposed Solution

Code

Sample Results