kwaclaw

About

Username
kwaclaw
Location
Oshawa, Canada
Joined
Visits
4
Last Active
Roles
Member
Organization
Personal
Name
Karl Waclawek

Comments

  • JMDeruty wrote: » But as Ice uses quite a lot code generation, it wouldn't reduce the need to have language specific winRT slice compilers. Well, if the code generator also generated a WinRT component, the resulting API would be automatical…
    in WinRT? Comment by kwaclaw November 2012
  • JMDeruty wrote: » In the context of a new startup, we could use too an "ICE for WinRT". We would probably use it in C# ourselves. From an implementation point of view it might be as simple as exposing a COM layer on top of Ice for C++ (as …
    in WinRT? Comment by kwaclaw November 2012
  • Tack wrote: » Along these lines, I've started hail, a transport layer implementing the Ice protocol for Node.js applications. What about Javascript clients?
  • Seconded flangel wrote: » Dear ZeroC team, I was wondering what your opinion is on Javascript support in ZeroC. With the increasing adoption rate of Javascript on the server, I see JS as the ideal language to make ICE a true internet communi…
  • bernard wrote: » Hi Karl, We don't have yet any definitive plans for WinRT / Metro apps support. Do you have a specific use-case in mind? Would you prefer to develop with C++/CX, C# or another programming language? Best regards, Bernard …
    in WinRT? Comment by kwaclaw March 2012
  • kwaclaw wrote: » It would be nice if the C# mapping for byte sequences could be optionally specified to map to a range within an array (similar to the C++ mapping options). That way one could avoid extra copying. .NET even defines the ArraySegm…
  • xdm wrote: » Hi Joost After looking a bit more to this issue seems that is not possible to run Ice applications as untrusted XAML Browser applications because socket operations are only allowed to trusted signed applications. I have battle…
  • Andy, afcarl wrote: » The ICE documentation is composed of 1900+ pages, largely redundant via multiple language support, a trivially small number of explained simple examples, and minimal explanation of the nuts-and-bolts stuff that makes-up …
  • Robustness of ICE afcarl wrote: » b) ICE has a VERY non-trivial learning curve, 2) ICE software while impressive, is still very far from Robust and intuitive, Andy, You made some very good observations, but I would like to commen…
  • Posted on behalf of my security architect: matthew wrote: » Object ids are not session ids, and should not be compared. With respect to securing object ids, you can no more secure your server via object ids, than you can secure your website wit…
  • matthew wrote: » Object ids are not session ids, and should not be compared. What would you consider the equivalent in Ice for a session? From a conceptual point of view a session just represents client-specific (conversational) state on…
  • michi wrote: » Just because the web is good for distributed computing with a human at one end of the connection does not mean that it also is good for distributed computing with computers at both ends of the connection. As far as I can see, no-one…
  • dwayne wrote: » You also need to compile SliceChecksumDict.ice as well as it is used by IceStorm.ice. IceStorm.ice also includes Identity.ice but I don't think it should be necessary to compile Identity.ice as the types it defines are not actually…
  • matthew wrote: » This is near the top of our priority list. Most likely Ice 3.4 will support IOCP under Windows. Note that on Linux and Mac Ice already uses epoll/kevent and so it is very efficient and highly scalable on these platforms. Wi…
  • michi wrote: » I don't think message passing changes the picture in any substantial way: pass messages that are too fine-grained, and the problem is the exact same one. Michi. The way I understood it was that the different syntactical cons…
  • michi wrote: » The "loose coupling" mantra is a red herring... I agree with everything - didn't mean to imply that I disagreed. michi wrote: » Now, clearly, intermediaries can be useful in distributed systems. No argument there. But XML …
  • michi wrote: » Premise: RPC and IDL require a least common denominator. Conclusion: RPC is fundamentally flawed. Whether we use Ice, CORBA, REST, WCF, SOAP, Erland, or whatever, all approaches require this least common denominator because, wit…
  • Game_Ender wrote: » I am curious if Zeroc has any articles (perhaps a news letter) which talks about the relative advantages of distributed systems built with ICE when compared to REST or pure message passing ones (for example Erlang)? Vino…
  • xdm wrote: » Hi Karl, I have made a fix similar to yours but not require to call SetLength int length = (int) (_stream.Length - _replySize); Byte[] buff = new Byte[length]; _stream.Position = _replySize; _stream.Read(buff, 0, …
  • kwaclaw wrote: » However, if this is the solution, it is not complete, as I now get an Ice.BadMagicException: Seems my fix was not good - apparently MemoryStream.SetLength clears the stream. Rearranging the order seems to work: int length =…
  • kwaclaw wrote: » I am not sure how I can reliably reproduce it, but as far as I can tell, the ReadCallback in IceConnection.cs class instantiates a non-resizable stream which then throws this exception when the need for expansion arises. Karl …
  • dwayne wrote: » I manually edited the *.csproj files and added it. Not ideal, but it met our needs. I played around with this approach and it seems the following recipe works also: * Add your Slice files to a Visual Studio project and o…
  • matthew wrote: » Karl, can you detail what exactly isn't working? Sure, My little demo app threw an Ice.OperationNotExistException when I was sure that both server and client (in this case it is a call-back) used the same slice definit…
  • matthew wrote: » If you must have two-wall callbacks you should also consider using AMI on the server side to avoid blocking the calling thread. Yes, that is what I am doing. Thanks for the advice.
  • dwayne wrote: » Silverlight 0.3 was not meant to support AMD. However, it still should not be generating uncompilable code when the amd keyword is present. I am trying to use the new socket transport with call-backs. Would client AMD not be…
  • benoit wrote: » Hi, If you're using Ice 3.3.0, you don't really need thread #2 Cheers, Benoit. Thanks, that helps. Karl
  • joshmoore wrote: » As for your architecture, if I were in your position I'd suggest coming up with a stable Ice server, using Spring internally. When it comes time for web services, you can either: * have a Java web container act as a client to …
  • Thank you for your feedback. joshmoore wrote: » Our initial implementation of the OMERO server was a Spring context within a JBoss server. We currently support both a JBoss and an Ice-based server, which was relatively straight-forward using Ice'…
  • matthew wrote: » Hi Karl, I'm not really sure what problems you are encountering. Perhaps if you expressed the question in more concrete terms, it would be easier to help you. For example, what lifecycle does the container impose, and why can't…
  • bernard wrote: » I think what you're asking about is the ability to call your EJBs from Ice clients, the Ice equivalent of JBoss IIOP. Yes, correct. bernard wrote: » In theory, this should be feasible. I suspect this would require a RM…