rc_hzMemberEric RCOrganization: www.genband.comProject: No project yet✭✭✭
Originally posted by Ctaesis I'd like to see a big darn example Ice project that does something reasonably useful, and integrates the various existing features in non-canned ways.
Don't get me wrong, the documentation is excellant, and the examples are presented quite well - from good to better to best. However, it would be really useful if ZeroC provided some complete application of moderate complexity, GPL'd of course, which really shows off it's product.
Who's with me? (Or does this already exist?)
Yes, it's also my problem about Ice! If some complete application of moderate complexity are presented, ICE will be easier to learn for many of us!
Looking for the src for the intel c++ compiler 8.0 under win32
I tried to compiler the source files with intel c++ 8.0 compiler,there were many errors as"error #69" and others,I tried to modify the source,but it's too many,i gave up.So i want to know if a version which supported intel c++ 8.0 of win32 will be published.Thanks in advance.
wyan
Is it possible to have a IDL to Slice (or WSDL to Slice), that wipe out features that are not handled (or not handled the same way) in both context.
It would be nice that the client can access a Webservice, an ORB and an Ice object with the same definition langage.
Is is possible to use ICE inside an Osgi framework ?
This may permit to use something else than webservice for communication in OSGi (www.osgi.org).
We are contemplating using Ice on a Real-Time OS such as Qnx or LynxOS so we will need to use thread priorities. Maybe need to create a thread attributes object that can be passed to an overloaded IceUtil::Thread::Thread() constructor. Haven't thought this through much yet so it needs a lot of thought.
Maybe something like this:
class ThreadAttributes {...}
Priority inheritance for mutexes is not on by default on some Real-Time OS's so Ice Mutex should also enable this either automatically or via a constructor argument.
Hi, Ice is great! very good work!
I have a question: maybe possibile and not too difficult to implement a GSSAPI module for secure interoperability between client and servers?
0
marcFloridaAdministrators, ZeroC StaffMarc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications EngineZeroC Staff
Hi, Ice is great! very good work!
I have a question: maybe possibile and not too difficult to implement a GSSAPI module for secure interoperability between client and servers?
Most likely this is possible, but it's not on our todo list due to the lack of (commercial) demand for such a feature.
One thing that we'd find very useful is the ability to scale IceStorm (I *think* this
is different than federating IceStorm...). That is, it would be nice to be able to
create multiple, distributed IceStorm servers that are 'delegates' of a central event
server registry. A client would connect to the registry and be given a handle
to one of the delegates. This delegation would be on the basis of the (sorry,
CORBA-term coming up) "ChannelName", not the client - so all posters and
subscribers to the same channel would be allocated to the same delegate,
automatically. Adding more delegates would allow the system to scale.
A clever registry would be able to do load-balancing, but a simple round-robin
approach would be nice to start. We have (in design) a highly distributed
telescope control system that relies heavily on events. A previous CORBA-based
system (different telescope) has a severe bottleneck in the centralized notification
service - we'd like to avoid that in this (bigger, faster) project.
Anyway, thanks for considering this - ICE is Nice (sorry).
0
marcFloridaAdministrators, ZeroC StaffMarc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications EngineZeroC Staff
Are you talking about the telescope as described in this paper:
If so, a very cool project, it's great to hear that you chose Ice for this If you would like to discuss a closer collaboration, please feel free to contact us at [email protected].
When a slice interface definition is translated into C++ we get amongst other things a nice abstract Ice::Object class with all the defined methods as abstract functions.
This is all well and good, but in some cases it would be nice to simply have a pure language specific version of the interface. Something that wasn't an Ice::Object.
This would be useful for making delegate objects or for combining the ice system with other third party classes that one may not want to put directly into the adapter or other parts of the reference counting framework
so within the object factory the developer not just only instanciates a new object, he also takes care about the unmarshalling from the stream.
and within the slice meta tags we could tell the slice compiler what type shall be used:
["cpp:MyOwnFoo"]
class Foo
{
};
just an idea
cu tom
0
Todor TodorovMemberTodor I. TodorovOrganization: SeonixProject: no project✭
First of all I would like to expres my thanks to you guys for greating this wonderfull framework.
I'm considering using Ice in my private project so I would like to know are there some bindings between Ice event loop and for example Qt or GTK event loop. Also if I'm considering to use some networking wrapper library like ACE are there some bindings between ACE reactor or proactor frameworks and Ice. Otherwise how it should be done if there are no the proper bindings.
Thanks
/Todor
0
marcFloridaAdministrators, ZeroC StaffMarc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications EngineZeroC Staff
First of all I would like to expres my thanks to you guys for greating this wonderfull framework.
I'm considering using Ice in my private project so I would like to know are there some bindings between Ice event loop and for example Qt or GTK event loop. Also if I'm considering to use some networking wrapper library like ACE are there some bindings between ACE reactor or proactor frameworks and Ice. Otherwise how it should be done if there are no the proper bindings.
Thanks
/Todor
Ice does not have an event loop; it uses a thread pool model (or thread per connection). This means that integration with existing event loops is neither possible nor necessary. You just have to make sure that your application is thread safe.
With the newfound popularity of Ruby, especially in combination with the Rails framework, ICE support would be wonderful. Having to use webservices to access back end functionality is distressing.
0
marcFloridaAdministrators, ZeroC StaffMarc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications EngineZeroC Staff
With the newfound popularity of Ruby, especially in combination with the Rails framework, ICE support would be wonderful. Having to use webservices to access back end functionality is distressing.
I looked at Ruby some time ago, and liked it very much. However, at this time it didn't have native threads, which made it unusable for Ice. Does Ruby have native thread support now?
Nope, Ruby's still missing native threads. As I'm interested in using Ruby as a caller and a native implementation won't be forthcoming how should I pursue integration? Wrap highlevel native C++ with a Ruby interface? Do you have a link for information on how to integrate non-supported runtime envrinments?
Ruby v2, which will start trickling out later this year apparently contains support for native threading. Though as Ruby's an open source codebase who knows when it will be released or precisely what features it will contain.
0
marcFloridaAdministrators, ZeroC StaffMarc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications EngineZeroC Staff
Nope, Ruby's still missing native threads. As I'm interested in using Ruby as a caller and a native implementation won't be forthcoming how should I pursue integration? Wrap highlevel native C++ with a Ruby interface? Do you have a link for information on how to integrate non-supported runtime envrinments?
If you only need client-side functionality, you could wrap C++ proxies in Ruby. For server-side integration, I'm afraid you are out of luck, as the C++ runtime will dispatch requests in native threads.
You could look at the Ice for PHP source code for examples. Ice for PHP also has only client-side integration.
(If you have further questions regarding this subject, please start a new thread. This thread is for a general discussion about new Ice features.)
0
bennyMemberJeff ChurchwardOrganization: University of QueenslandProject: Quantum Mechanincs Simulation✭
Slightly off thread .... this is more about what I'd like to see on the Ice Web site and in Connections.
What about doing some success stories or features on your clients and users. I would like to know how Ice has been used in application in the commercial and research world. There might be some wierd and interesting uses, approaches and tricks that we could all learn from .... a sort of knowledge database! Maybe some of this will trickle down to more advanced examples being included.
Many thanks for the excellent documentation .... and clean, easy to read code.
I believe ICE is better than CORBA. And I am wondering why ICE does not support Delphi ,as we prefer to build client side with Delphi.
Since ICE has been mapped to VB, why not Delphi?
0
marcFloridaAdministrators, ZeroC StaffMarc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications EngineZeroC Staff
Doing a language mapping is a lot of work, and our priorities are driven by the needs of commercial customers. While many users expressed interest in Ice for Delphi on this message board in general, so far nobody had any commercial interest in such a product. In case you have a commercial need for Ice for Delphi, please contact us at [email protected].
0
acbellMemberAndrew BellOrganization: Iowa State UniversityProject: National Resources Inventory✭✭
Small Enhancement Request
Hi,
This isn't a big deal, but I would like to see a way to get the remote/local address without parsing the result of Connection::toString().
What about a shared memory Endpoint. I noticed Ice already has UdpEndpoint and TcpEndpoint. Would it be possible to create a shared memory version that bypasses the networking layer completetly?
Given that how about making the optimization at a higher level? Ice already has a local invoke optimization wereby if client and server are in the same ObjectAdapter the runtime will "bypass much of the overhead of call dispatch" as the manual says.
Could the shared memory optimization be made at this level too? That is can it avoid the marshaling step? Come to think of it does the local invoke even avoid marshaling. The data marshaling is done very early in the generated stubs.
Thanks,
0
marcFloridaAdministrators, ZeroC StaffMarc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications EngineZeroC Staff
As you write, a shared memory transport would only make sense if we would avoid marshaling altogether, otherwise there would only be little performance gain.
However, this would be quite an intrusive change. In essence, it would be a completely different protocol, with completely different stubs and skeletons. It could not be implemented as a transport plug-in like UDP or SSL, as these work underneath the Ice protocol engine, which requires data encoding (marshaling).
While this is doable in theory, it's rather unlikely that we implement this, as the performance gains are limited to interprocess communications on a single machine. Having said this, if you have a commercial need for such a transport, please feel free to contact us at [email protected]
The collocation optimization bypasses marshaling completely. But it's quite different from a shared memory transport, because the collocation optimization does not use any data buffering; instead, it uses direct invocations from the proxy on the skeleton, which can only work if client and server are linked together in the same process.
Comments
Yes, it's also my problem about Ice! If some complete application of moderate complexity are presented, ICE will be easier to learn for many of us!
I tried to compiler the source files with intel c++ 8.0 compiler,there were many errors as"error #69" and others,I tried to modify the source,but it's too many,i gave up.So i want to know if a version which supported intel c++ 8.0 of win32 will be published.Thanks in advance.
wyan
Is it possible to have a IDL to Slice (or WSDL to Slice), that wipe out features that are not handled (or not handled the same way) in both context.
It would be nice that the client can access a Webservice, an ORB and an Ice object with the same definition langage.
Is is possible to use ICE inside an Osgi framework ?
This may permit to use something else than webservice for communication in OSGi (www.osgi.org).
Thank you for your feedback.
Borland C++ compiler support wantted!
At this time, we have no plan to support any non-Microsoft C++ compiler on Windows.
Best regards,
Bernard
We are contemplating using Ice on a Real-Time OS such as Qnx or LynxOS so we will need to use thread priorities. Maybe need to create a thread attributes object that can be passed to an overloaded IceUtil::Thread::Thread() constructor. Haven't thought this through much yet so it needs a lot of thought.
Maybe something like this:
class ThreadAttributes {...}
Priority inheritance for mutexes is not on by default on some Real-Time OS's so Ice Mutex should also enable this either automatically or via a constructor argument.
-john
Hi, Ice is great! very good work!
I have a question: maybe possibile and not too difficult to implement a GSSAPI module for secure interoperability between client and servers?
Most likely this is possible, but it's not on our todo list due to the lack of (commercial) demand for such a feature.
Hi folks,
One thing that we'd find very useful is the ability to scale IceStorm (I *think* this
is different than federating IceStorm...). That is, it would be nice to be able to
create multiple, distributed IceStorm servers that are 'delegates' of a central event
server registry. A client would connect to the registry and be given a handle
to one of the delegates. This delegation would be on the basis of the (sorry,
CORBA-term coming up) "ChannelName", not the client - so all posters and
subscribers to the same channel would be allocated to the same delegate,
automatically. Adding more delegates would allow the system to scale.
A clever registry would be able to do load-balancing, but a simple round-robin
approach would be nice to start. We have (in design) a highly distributed
telescope control system that relies heavily on events. A previous CORBA-based
system (different telescope) has a severe bottleneck in the centralized notification
service - we'd like to avoid that in this (bigger, faster) project.
Anyway, thanks for considering this - ICE is Nice (sorry).
http://atst.nso.edu/library/spie/5496-40.pdf
If so, a very cool project, it's great to hear that you chose Ice for this
When a slice interface definition is translated into C++ we get amongst other things a nice abstract Ice::Object class with all the defined methods as abstract functions.
This is all well and good, but in some cases it would be nice to simply have a pure language specific version of the interface. Something that wasn't an Ice::Object.
This would be useful for making delegate objects or for combining the ice system with other third party classes that one may not want to put directly into the adapter or other parts of the reference counting framework
Being able to control the specific c++ typemapping (within the std framework possibly) with slice metatags would be nice
the ObjectFactory could be used for this with a method like this: so within the object factory the developer not just only instanciates a new object, he also takes care about the unmarshalling from the stream.
and within the slice meta tags we could tell the slice compiler what type shall be used:
["cpp:MyOwnFoo"] class Foo { };just an idea
cu tom
I'm considering using Ice in my private project so I would like to know are there some bindings between Ice event loop and for example Qt or GTK event loop. Also if I'm considering to use some networking wrapper library like ACE are there some bindings between ACE reactor or proactor frameworks and Ice. Otherwise how it should be done if there are no the proper bindings.
Thanks
/Todor
Ice does not have an event loop; it uses a thread pool model (or thread per connection). This means that integration with existing event loops is neither possible nor necessary. You just have to make sure that your application is thread safe.
I looked at Ruby some time ago, and liked it very much. However, at this time it didn't have native threads, which made it unusable for Ice. Does Ruby have native thread support now?
Ruby v2, which will start trickling out later this year apparently contains support for native threading. Though as Ruby's an open source codebase who knows when it will be released or precisely what features it will contain.
If you only need client-side functionality, you could wrap C++ proxies in Ruby. For server-side integration, I'm afraid you are out of luck, as the C++ runtime will dispatch requests in native threads.
You could look at the Ice for PHP source code for examples. Ice for PHP also has only client-side integration.
(If you have further questions regarding this subject, please start a new thread. This thread is for a general discussion about new Ice features.)
What about doing some success stories or features on your clients and users. I would like to know how Ice has been used in application in the commercial and research world. There might be some wierd and interesting uses, approaches and tricks that we could all learn from .... a sort of knowledge database! Maybe some of this will trickle down to more advanced examples being included.
Many thanks for the excellent documentation .... and clean, easy to read code.
I believe ICE is better than CORBA. And I am wondering why ICE does not support Delphi ,as we prefer to build client side with Delphi.
Since ICE has been mapped to VB, why not Delphi?
Hi,
This isn't a big deal, but I would like to see a way to get the remote/local address without parsing the result of Connection::toString().
Thanks,
-- Andrew Bell
[email protected]
I agree. This is already on our todo list. (But I can't give you any release date for this feature yet.)
Given that how about making the optimization at a higher level? Ice already has a local invoke optimization wereby if client and server are in the same ObjectAdapter the runtime will "bypass much of the overhead of call dispatch" as the manual says.
Could the shared memory optimization be made at this level too? That is can it avoid the marshaling step? Come to think of it does the local invoke even avoid marshaling. The data marshaling is done very early in the generated stubs.
Thanks,
However, this would be quite an intrusive change. In essence, it would be a completely different protocol, with completely different stubs and skeletons. It could not be implemented as a transport plug-in like UDP or SSL, as these work underneath the Ice protocol engine, which requires data encoding (marshaling).
While this is doable in theory, it's rather unlikely that we implement this, as the performance gains are limited to interprocess communications on a single machine. Having said this, if you have a commercial need for such a transport, please feel free to contact us at [email protected]
The collocation optimization bypasses marshaling completely. But it's quite different from a shared memory transport, because the collocation optimization does not use any data buffering; instead, it uses direct invocations from the proxy on the skeleton, which can only work if client and server are linked together in the same process.
ICE now have twoway,oneway,batch,timeout invocations.But how can I make a delay invocation? Just like this:
The operation return immediately,but the call will be sent to server by ice runtime 50 milliseconds later.
Cheers,
Michi.