Re: Trial for RDi SOA

Joe Pluta skrev den 15-05-2008 21:09:

I have not played around with the demo application so I have no idea of the actual functionality, but am only responing based on your outline.

And I'll try to respond generally, but I really am asking people to give me real estimates for how long it would take, since that's the real issue: how productive can you be?

Excellent question :)

Unauthenticated services:
1. View sessions and tracks, with times
2. View descriptions, votes and tags
3. View comments in realtime
4. Find current sessions
5. Search sessions on keywords

Unauthenticated means no sessions. Ok. Not bad. Real time means SQL.

Not SQL. Calls to RPG.

As opposed to having static HTML pages generated periodically, not by choosing way to pick out data from the server.

Authenticated services
1. Register/login (we use email authentication)
2. Maintain schedule
3. Social networking: votes, tags, comments
4. Recommend sessions
5. Online chat

Chat means Ajax. Jetty has a demo application, I'll just nick... eh... adapt.

A bit more than that. Chat sessions are specific to sessions. You click on a session's chat button and you're placed there. Comments are stored in the database, so that people can view past comments as well as watch (and participate in) ongoing conversations.

Ah. A chatroom per session with a history.

Administrative services
1. Maintain sessions and tracks
2. Enable/disable users
3. Clear/maintain tags, votes and comments

Hmm... Would a "Keep stuff in a spreadsheet and upload new versions with changes" do?

Nope. Users are added by people registering - wouldn't show up in spreadsheet. Either would any of the social networking stuff. That's why spreadsheets (to put it politely) suck for real applications.

Sure. Depends on the amount of work to put into the task at hand.

All data is to be stored on the System i. Responses for the most part should be subsecond.

Naturally. I have just played around with pooled java toolbox connections where the overhead for doing a program call is 1-2 ms, so it CAN be done :)

Would such a challenge include data files so we just talk creating functionality or would everything have to be made from scratch?

Well, we created everything from scratch. Why shouldn't you? <grin>

Since your "challenge" was to see how much time it takes to implement functionality in technology X, not how much time it takes to build something from zero, it would not be unreasonable to provide the data you have for the thing to reimplement.

The RSDC scheduler is a benchmark. I'd love to see it reproduced using any technology, so that we can compare approaches.

I have no idea what you are talking about :)

I'm tired of listening to everyone say how good (TECHNOLOGY X) is. Time to prove it. It's easy to sit on a mailing list and pontificate. It's a lot harder to really do something.

Oh, the RSDC is the application we are discussing. Thought it was some kind of Rational Super Duper Checkmark thing we had to use.

Personally I do not say that EGL is better or worse than anything else, I just say that _I_ am very careful of meta-languages since the additional translation step may be extremely hard to debug. Just look at how long it took before JSP's were debuggable - that was painful.

But we've done it, so now it's time for others to match it.

Depends on the task at hand ;-)

I would love to see the Ruby on Rails people take a stab at this.