Re: Idle curiosity about EGL Cafe ...

David Gibbs wrote:

Joe Pluta wrote:

Look about halfway down, you'll see comments about the scheduler. Note the reference to "and use inventive technology that suggests which talks the user should attend next based on preferences" - that's actually the most complex business logic. I wrote a routine in RPG that identifies sessions to attend based on tag weights.

Based on the description, I would consider the scheduler less of a
business application than a forum system. JMO, of course.

Hmmm? What part of a forum system do you think requires complex business logic?

Now, if that sort of business logic were included in a forum, and highlighted in the "about pages" for the forum, you might change my mind.

That's certainly a worthwhile function for a forum system, imo.

I agree. But very few forums have things like "find posts based on my preferences". They have text searches, but nothing that really requires much business logic. And THAT is why I say that most forums don't have much business logic.

I mean, really, if you want to push this argument, we'd have to return to your list and decide what part of it is actually hard. How much code do you think is involved in, say, threading? Do you consider that to be anywhere near the level of complexity of the sorts of things you've programmed in your career? I certainly don't.

Somehow, I suspect, EGL with a hand crafted RPG back end is *NOT* what
IBM is really going to push. This also is JMHO.

What is "IBM"? There are a lot of factions in IBM. There are people who promote EGL as a cross-platform language. There are those who promote it as a means to modernize existing midrange applications reusing business logic. The former won't push RPG, the latter will.

This is a tough argument. Progress for the sake of progress.

From my experience, progress for the sake of progress rarely succeeds
... progress for the sake of new, required, capability will. If you
need capability, and can improve upon the existing offerings, why not
redevelop it?

Cost? If you have something that already works well enough, why reinvent the wheel?

To be honest, the only way I'd see this making sense is if IBM were planning to *market* the EGL Cafe software. Then they'd be able to create a revenue stream that would justify the money spent developing
the product.

"IBM Rational User Forum module for Portal"?

Right. But is there enough of a market to justify the cost?

Honestly, I see your point: writing a forum in EGL would be a great way to showcase EGL. But how much investment would it take to do correctly? And how much revenue would it really generate?

Depends on who's looking at it, I guess. But that's the case for
everything. If I'm looking for a development environment to write a new
system, one of the first things I want to see is what's been written
with it already so I can get a sense of what kind of things it can do.

Part and parcel of IBM's marketing of EGL should be a showcase of
existing applications that you can play with and see the source.

Here's a forum application we wrote ... see how flexible it is ...
here's the source for it ... see how easy it was to write?

I don't think that's the case for EGL/JSF, but I think you will see more of that for the RUI stuff.

Authentication is a commodity service.

As part of authentication I should have included managing user
preferences and authority levels. These are part of most business
applications.

Okay. Still not rocket science. Definitely a business function, though. But not a difficult one.

The database requirements are very simplistic.

Dunno about that ... store the message, store the meta data, store the
threading information, store the user preferences, etc, etc, etc.

Database requirements for most applications are fairly simplistic at the
core.

Database design for an ERP application far outstrips anything in a forum. If you don't think so, then I don't think you've looked at an ERP system in a while.

And while thread management isn't exactly trivial, it doesn't hold a candle to requirements processing or costing or pricing ... or all the stuff we use a business machine for.

Discussion thread management can be very complex. Here's a message,
figure out what messages it's related to. Oh, it came in from a
different input than the primary interface, figure out what messages
it's related to. Can't figure it out adequately, make an educated guess.

"Very complex"? One algorithm to determine the related message. Exactly how long do you think that will take to write? I'm sorry, but this just isn't that tough, especially for a web-based forum, which doesn't need any such things because you know which message it's related to when you post it - it's the one they replied to.

I realize that comparing relative difficulty is an imprecise process, but discussion thread management simply isn't rocket science, and that's the most difficult thing on your list.

You want to say that forum software is as difficult as, say, order entry, then fine. Be my guest. We'll just have to have differing opinions on that. I don't know how many people on these lists would agree with you.

Our scheduler did online realtime chats, commenting, voting, tagging,
and authentication via email. Not to mention rendering. That's the
framework for just about everything above.

Then it's not a scheduler ... it's a whole lot more. FWIW: What you
describe there sounds kind of like the beginnings of community based
forum system.

Yeah, it's a whole lot more. It was much of the framework for a forum. And it required about 1500 lines of RPG. That's why I can say without reservation that forums don't hold a candle to an ERP system. The business logic in a simple pick list processor is probably more complex than that in most forum software.

There's simply no way you're going to tell me that forum software will somehow tax the programming capabilities of a good RPG programmer. You might have one or two tricky algorithms, and then the rest is pretty much low-level stuff.

In my opinion, a forum doesn't need an i and it certainly doesn't showcase the business logic capabilities of the box. But that's my opinion.

Neither does a scheduler.

Never said it did, David! The development process, on the other hand - me and Chris in separate parts of the country developing using only WSDLs and EGL record definitions - definitely proved that EGL can be part of a true SOA development environment. THAT'S what we proved. And that RPG can be a first-level player in that space.

Anyway, since as you say you would never buy EGL anyway, this hypothetical exercise has consumed enough time. Interesting, though. I'll take a look at some forums software again and see if it's anywhere near as complex as you think it is. I can always stand to learn a few things.

Joe