Hi all -

Does anyone remember what Mike R. said at the Rev conference about a 64-bit OI?

TIA, Mike O.

That they had test compiled under 64 bit and expected no problems but would be holding off on the port until enough of the market indicated they wanted it.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

…until enough of the market indicated they wanted it…

Do you know of anybody who doesn't want multi-threading?

Wilhelm

Interesting question if taking the original response a little out of context. This is a discussion we have in the office quite a bit… would you be prepared to pay for a user license per thread? What would you actually want multithreading for that can't be achieved by spawning engines?

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Interesting question if taking the original response a little out of context.

Admittedly my brain is very foggy on the original statement but I thought the market demand issue was mainly for 64-bit processing and not necessarily for multi-threading.

… would you be prepared to pay for a user license per thread?

Is that just a question of supposition or do you actually know this is how it would be marketed? Is there a precedent for equating threads for user licenses? Off hand I wouldn't think that as being kosher, especially since we are aiming to make any one user more efficient. Multi-threading does not turn a single-license into a multi-user/multi-machine system.

What would you actually want multithreading for that can't be achieved by spawning engines?

Anything requiring the presentation server. Background printing would be a good example. (Granted this can be done with OLE…but that requires a rewrite of the OIPI to support it.) This would also make it easier to design processes that rely on the status of other concurrent processes.

[email protected]

SRP Computer Solutions, Inc.

But how would you prevent the additional threads being used to service database requests for other users? This might require reengineering the entire product so that database requests are routed via an engine which tracks thread ids and decrements user counts based on that. It all becomes horrendously complicated.

I hasten to add that this is all internal speculation about how we'd try to achieve it if we were in Revelation's position. Licensing is a pain as we've seen with the WDP and Web Access. How do Revelation get a return on investment without making things unecessarily complex?

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Licensing under multithreading could/should obviously require a different approach, maybe by CPU or some other type of flat-rate.

Remote & dynamic engines have given OI a lot of flexibility, this is a fact we recognize and appreciate.

Some ideas, that come into my mind, on what we would do with multithreading (please correct me, if I'm daydreaming):

[*]Connect to webservices in a transparent environment (tomcat, java, jdbc), putting aside the restrictions of the CGI.

[*]No more overhead in loading DBT and EXE files for dynamic engines. Memory management on the server is said to be much more efficient under multithreading.

[*]Complex writes could be handled in parallel, instead of sequential processing

[*]Selects (and thus reports) wouldn´t have to wait until finishing the selection, could work with intermediate results etc.

More efficient (and more intelligent) web-/file servers drastically improve response times in heavy workload environments.

Wilhelm

Therein lies the rub… it would not be enough to create a muti-threaded version of the engine to do these things. These would pretty much all require significant reengineering of the underlying core routines. Just because an engine is multithreaded does not make the select processor return partial results for example. So what is being asked for is not a "multithreaded engine" it is a multithreaded engine and a significant redesign of the underlying architecture.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

I hasten to add that we're not anti the concept of multithreading - we can see SOME benefits. We just talk a lot internally about the implications around the proverbialy watercooler and simply creating a multithreaded engine adds little to existing functionality that cannot be addressed with marshalled engine farms.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

I see your point.

Could you imagine hybrid options (allowing webservices, for example), without having to redo almost everything in OI?

Wilhelm

Web Services are already theoretically possible and we have implemented something like this already for a client but I'll stop here lest this become an infomercial. :)

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

View this thread on the forum...