ttime on the web

[eyal]

I suggest ttime will be ported to a web application
this will allow ttime to be accessible from every computer in the
technion and won't require installation

I think we can use google's gwt and appengine to do so

anyway, I intend to start the porting ASAP, everyone is welcome to
join me

[Ohad Lutzky]

This is a welcome project, but I have a few remarks:

1. Rendering the schedule properly in HTML is hard work. The schedule looks great in ttime, and not-so-great in Marprog and UDonkey. Be prepared for this.

2. TTime is already installed on every Linux computer in the CS farm and DSL . Thanks, Tzafrir!

3. Searching for schedules is an extremely long process, especially for early semesters - those have many options. This is why we haven't done a web-based ttime yet - it is very dependant on the local CPU. One option is implementing the search in Javascript - Chrome's implementation is blazing fast.

--
Man is the only animal that laughs and weeps, for he is the only animal that is struck with the difference between what things are and what they ought to be.
- William Hazlitt

Ohad Lutzky

[Eyal Kibbar]

I can see that you did not look at GWT and App Engine

1. we don't need to write html, GWT offers a swing like interface for creating gui on a web browser using java ONLY.
2. you are right, it is installed on every CS computer, but what about every other computer in the technion
    for instance, I sometimes want a quick check to see what is my next lecture/tutorial and I don't want to login the farm's computer,
    I rather go to the library computer which doesn't require login
3. App Engine provides us with a state of the art parallel computer farms, all the calculations can be done on the SERVER.
    but if u still prefer calculations on local cpu, GWT provides a java to javascript compiler with built in javascript optimization thus the javascript code will be extremely optimize for the user's browser, OS and cpu.

[Ohad Lutzky]

Sounds good. I hope you use git for version control, and start out with our REPY parser (it's as clean and fast as we could get it).

[Eyal Kibbar]

1. I'm used to svn, but I can change
2. we don't need REPY parser, we only need to parse once and upload the parsed data to the server

[Ohad Lutzky]

On Fri, Sep 18, 2009 at 2:57 PM, Eyal Kibbar <eyal....@gmail.com> wrote:

1. I'm used to svn, but I can change

SVN sucks. Here's an explanation: http://www.youtube.com/watch?v=4XpnKHJAok8

Git is pretty easy to learn nowadays, and will greatly help development, especially if you'd like others (...such as myself...) to easily be able to help.

 

2. we don't need REPY parser, we only need to parse once and upload the parsed data to the server

Once... per semester. If this is the case, do you intend to use ttime's XML output feature, for udonkey-compatible XML? UDonkey's XML format is not ideal.

[boaz goldstein]

so, rewrite the GUI with java and GWT, and connect it with JRuby?
only one question. who pays for the Google App Engine?

On Sep 18, 3:08 pm, Ohad Lutzky <lut...@gmail.com> wrote:

> On Fri, Sep 18, 2009 at 2:57 PM, Eyal Kibbar <eyal.kib...@gmail.com> wrote:
> > 1. I'm used to svn, but I can change
>
> SVN sucks. Here's an explanation:http://www.youtube.com/watch?v=4XpnKHJAok8
>
> Git is pretty easy to learn nowadays, and will greatly help development,
> especially if you'd like others (...such as myself...) to easily be able to
> help.
>
> > 2. we don't need REPY parser, we only need to parse once and upload the
> > parsed data to the server
>
> Once... per semester. If this is the case, do you intend to use ttime's XML
> output feature, for udonkey-compatible XML? UDonkey's XML format is not
> ideal.
>
>
>
>
>
> > On Fri, Sep 18, 2009 at 2:52 PM, Ohad Lutzky <lut...@gmail.com> wrote:
>
> >> Sounds good. I hope you use git for version control, and start out with
> >> our REPY parser (it's as clean and fast as we could get it).
>

> >> On Fri, Sep 18, 2009 at 2:45 PM, Eyal Kibbar <eyal.kib...@gmail.com>wrote:
>
> >>> I can see that you did not look at GWT<http://code.google.com/webtoolkit/>and App
> >>> Engine <http://code.google.com/appengine/>

>
> >>> 1. we don't need to write html, GWT offers a swing like interface for
> >>> creating gui on a web browser using java ONLY.

> >>> 2. you are right, it is installed on every *CS* computer, but what about

> >>> every other computer in the technion
> >>>     for instance, I sometimes want a quick check to see what is my next
> >>> lecture/tutorial and I don't want to login the farm's computer,
> >>>     I rather go to the library computer which doesn't require login
> >>> 3. App Engine provides us with a state of the art parallel computer
> >>> farms, all the calculations can be done on the SERVER.
> >>>     but if u still prefer calculations on local cpu, GWT provides a java
> >>> to javascript compiler with built in javascript optimization thus the
> >>> javascript code will be extremely optimize for the user's browser, OS and
> >>> cpu.
>
> >>> On Fri, Sep 18, 2009 at 2:31 PM, Ohad Lutzky <lut...@gmail.com> wrote:
>
> >>>> This is a welcome project, but I have a few remarks:
> >>>> 1. Rendering the schedule properly in HTML is hard work. The schedule
> >>>> looks great in ttime, and not-so-great in Marprog and UDonkey. Be prepared
> >>>> for this.
> >>>> 2. TTime is already installed on every Linux computer in the CS farm and

> >>>> DSL [?]. Thanks, Tzafrir!

> >>>> 3. Searching for schedules is an extremely long process, especially for
> >>>> early semesters - those have many options. This is why we haven't done a
> >>>> web-based ttime yet - it is very dependant on the local CPU. One option is
> >>>> implementing the search in Javascript - Chrome's implementation is blazing
> >>>> fast.
>

>  347.gif
> < 1KViewDownload

[Ohad Lutzky]

Is there any real reason to write this in JRuby? JRuby is rather slow atm, and I don't really like the concept. Java may be lengthy to write, but it is typesafe and - once the VM is up and running - fast.

Google App Engine is free for basic service, up to 5 million pageviews.