Ice Framework Rationale

[Werm]

Hi there,

I've recently found the whole Ice thing and have been doing some reading now.

I've been using CORBA for a long time and, quite frankly, the spec is poo.

I found Ice when I was thinking about puting together a simple system myself. After looking at the spec I've got a few questions/comemnts so here they are in no particular order. I expect some robust discussion will come of it, so I'll just disclaim right now that I'm not trying to be negative or troll. :-P

1)

Whats the deal with classes/interfaces/structs guys? Are plain old interfaces not good enough? I like that we don't have attributes, uniform access is good.

Someone needs to explain to me though why you've got the whole class/interface dichotomy going on.

What kinds of things can you build with them that are impossible without?

2)

You guys seem to be concerned with protocol efficiency over everything else. Do you think this is a fair comment? What are the most important axes for Ice? (orthogonality,protocol efficiency,ease of use, ease of implementation,portability across languages,protability across machines)

3)

No underscores in slice? You've got to be kidding. Surely you're not going to make everyone use the stupid and illegible java naming convention!?!?

4)

Why do co-lo calls using different communicators in the same address space not dispatch directly? Or have I read this wrong? (in a couple of places)

5)

Go on, explain why contexts exist if they have been the bane of everyone's lives? I remember lots of discussions on USENET where Michi seemed like he'd want to flay them from the CORBA spec.

6)

Why the GPL instead of LGPL or another license?

7)

Why bother with oneway at all?

8)

Any plans for other language bindings? C? Perl? Python? Ruby?

How do you see the threading models used in Ice affecting the ease of implimetation in the above languages?

Thats it for now really.

Cheers,

w

[marc]

Re: 1

Classes can have data members, interfaces cannot. With classes, you can implement objects-by-value, and they offer automatic persistence with Freeze. Interfaces, on the other hand, allow multiple inheritance, which classes do not allow (just like in Java).

Structs are different: They are "plain old data", and therefore very efficient. It's similar to the struct concept in C# or "plain old structs" in C++.

Re: 2

Protocol efficiency is only one aspect that was important for us. Simplicity is even more important. And the two are not mutual exclusive

Re: 3

We don't allow underscores to avoid name clashes with built-in operations. I know there are other ways to avoid this, but completely reserving underscores for built-in stuff makes Ice a lot simpler.

Re: 4

Two different communicators are like two different Ice instances in one process. For example, if you use DLL with Ice stuff, and each DLL has its own communicator, then there can be no side effects if you use these two DLLs together.

Re: 5

Don't confuse the contexts in Ice with CORBA IDL contexts. The have nothing to do with the evil CORBA IDL contexts Ice contexts are more like GIOP service contexts. For example, you can use contexts to pass routing hints (like for Glacier).

Re: 6

We use GPL, because if somebody wants to write a closed-source application, then they have to buy a commercial license from us.

Re: 7

Because oneways are necessary, just as other forms of async messaging are necessary. In many cases, you do not want to block a request to wait for a response from the server. It is simply much more efficient in certain contexts.

Re: 8

We currently have plans to add a C# mapping to the already existing C++, Java, and PHP mappings. We believe that we can use our leader/follower model in most languages. If not, we will have to find a different threading model for such language.

[Werm]

Cheers for the vitesse reply.

Right, lets get a bit more detailed then. :-)

1)

Yep. I understand the differences between interfaces, classes and structs.

What I don't really understand at the moment is why you have included classes as part of the slice language.

When OBV got shoved into the CORBA spec pretty much everyone took one look at it and just had to take a big deep breath because suddenly implementation transparency had been thrown out the window.

If you're process doesn't have an implementation for the class then you're shafted.

So, given that, what's the rationale for including OBV into Ice? What does it let me do that cannot be done another way? Is it merely for reasons of efficiency? What trade-off is being made here?

At the end of the day I can easily see the utility of structs that can be subclassed and inherit from others but OBV with implementations that have to be provided on every client you have is just a nightmare.

Or tell me I'm wrong! Please!! How do I use OBV without deploying code to every client (on every OS, in every language, and language version) that I have?


3)

Would you mind if someone were to release a patched Ice with underscores allowed then? :-)


4)

Okay, cool. I think I can see why you want to do this. I may go and have a more in depth look at it though. What kind of side-effects are we avoiding here?


5)

Ah yes. *phew*


6)

Hmm...I need to go and think about your licensing. I'm not sure how it's meant to work.

Are you saying that linking to the ice libraries constitutes a derivative work under the terms of the GPL?

How about if I don't distribute anything but instead use ice to build my infrastructure on a set of servers that run my business? What if these include web servers?

How does me paying for a licence stop me having to distribute my source under the GPL?


7)

Efficient or neccessary? I'd be interested to see a case where they are neccessary.


NEW 9)

So, are you looking for people to implement other bindings for you? Or will all official Ice development be done by zeroc people?

Cheers,

w

[marc]

Re: 1

In most cases, you will use non-abstract classes, meaning classes that do not have operations, and therefore do not require an implementation. Hierarchies of such classes are also used instead of unions or anys. This is IMO much cleaner than unions or anys.

You can also transmit classes with operations (abstract classes), but this requires a factory at the receiving end. There is no magic transmission of implementation. This can be useful for load-balancing. For example, if you have equivalent servers, and you want to move an Ice object from one server to another, you can transmit such an Ice object by value.

Most importantly, classes with both operations and data members are used for persistence. Slice is not only an interface specification language, but also a persistent state specification language. You can define a class with data members and operations, add a local implementation, and let the Freeze evictor handle the persistence. This way, it's very easy to add highly-scaleable persistent Ice objects to your application.

Re: 3

Sure, if this is so important for you

Re: 4

Collocation-optimized calls are not 100% location transparent. That's a trade-off between performance and "purity". For example, collocation-optimized calls are always executed in the caller thread, not in the server thread pool. And return values by-reference (Java reference, C++ smart pointer) are not copied. (Because of the slightly different semantics of collocation-optimized calls it's possible to disable collocation optimization on a per-proxy basis.)

Re: 6

There is a very good FAQ about the GPL at http://www.gnu.org/licenses/gpl-faq.html. In short, if you don't distribute your closed-source application, you can use Ice under the terms of the GPL.

If you buy a commercial license from us, then the terms of this commercial license apply instead of the terms of the GPL, meaning that our commercial license would give you the right to redistribute your application as closed-source.

Re: 7

Efficiency is for many applications a necessity. Consider the alternative if you want to invoke an operation that takes long to execute on the server without having to wait for the result. You would have to do such an invocation in a separate thread. If you have many such invocations, the overhead might simply become too high. (Besides, it's more code to write.)

The same applies for AMI and AMD. In theory, if you would have unlimited processing power and thread resources, you would not need them. But real-world applications have to obey to constraints set by their operating environment.

Re: 9

If you would like to implement a language mapping, we would certainly support you in doing so! Note that somebody already started working on a Python mapping. Have a look at http://www.zeroc.com/vbulletin/showt...p?threadid=146.

[michi]

Hi Werm,

Marc has beaten me to the punch on most of your points, so just a few additional comments from me...

Originally posted by Werm
What I don't really understand at the moment is why you have included classes as part of the slice language.

When OBV got shoved into the CORBA spec pretty much everyone took one look at it and just had to take a big deep breath because suddenly implementation transparency had been thrown out the window.

Well, I'm on record as an OBV hater, and I was one of the people who argued that we should try to find ways to live without classes in Ice (but Marc eventually made me see the error of my ways )

For one thing, Ice classes are much simpler than CORBA value types: no boxing, no non-truncatability, no constructors, no private and public section, etc. (CORBA value types originally started out with someone saying "Let's do structs with inheritance" and went out of control from there...)

As I said in the doc, classes with operations are a two-edged sword: if you cannot control the deployment environment on both client and server side, you can end up with a porting nightmare. On the other hand, for those situations where you do control the deployment environment, classes with operations can be truly useful -- they provide a way to do client-side processing that is nicely encapsulated (which is something that you cannot do with interfaces).

And, of course, you can always use classes without operations, in which case, you end up with structs with inheritance. (The reason that we retained structs is that they are a lot more efficient, both in terms of memory management and marshaling: structs can't be self-referential, so there there is no need to dynamically allocate things or to do garbage collections, and structs can't be sliced, which requires a fair bit of machinery in the marshaling code to make work correctly.) And, of course, classes without operations don't have any of the potential problems that classes with operations do.

Would you mind if someone were to release a patched Ice with underscores allowed then? :-)

I would actually Have a look at http://www.zeroc.com/vbulletin/showt...=&threadid=84.

There was a discussion about just this topic previously. I know, it rubs up a lot of people the wrong way. But the alternatives are worse, I believe. And, to be honest, to me, whether a language allows underscores in its identifiers is about a 10th-order issue -- there are a lot of things to worry about that are far more important. As I said earlier, people got along just fine in COBOL, FORTRAN, BASIC, and Pascal for years, all without underscores...

Cheers,

Michi.

[Werm]

Classes

Right, I'm going to go off and think about this. I see what you guys are saying, but I'm not quite ready yet to agree.

If you have any good examples of where you think using classes with operations is a Good Idea(tm) then bring them on, I'd be grateful for any examples that make me think. "Oh yeah, that's quite cool."

Thanks for wading in Michi, I remember talking to you on c.o.corba ages ago about exactly these issues.


GPL/Licensing

IANAL and all that.

What are you charging people for then? If they have the code then they have the right to use it. You can't stop someone from using the code gratis once they have downloaded and built it. (I mean legally, not just practically)

Correct me if I'm wrong. Please. I have read the GNU literature. I may not completely understand it of course.


Extra Languages

So, what kind of access will you provide someone wanting to create another language binding?

How would you go about creating a language binding for a single-threaded language, or one where multithreading was not available/stable?


Underscores

Yes, I know and understand the arguments. I still disagree. This may be a religious issue. I also understand when you say it's a 10th order issue on the priority list.

w

[marc]

Originally posted by Werm
Classes

Right, I'm going to go off and think about this. I see what you guys are saying, but I'm not quite ready yet to agree.

If you have any good examples of where you think using classes with operations is a Good Idea(tm) then bring them on, I'd be grateful for any examples that make me think. "Oh yeah, that's quite cool."

Thanks for wading in Michi, I remember talking to you on c.o.corba ages ago about exactly these issues.

The strongest use case is persistence. Check out the Freeze demos in demo/ice/Freeze. As you will see, adding persistence to an Ice application is very easy.

Originally posted by Werm
GPL/Licensing

IANAL and all that.

What are you charging people for then? If they have the code then they have the right to use it. You can't stop someone from using the code gratis once they have downloaded and built it. (I mean legally, not just practically)

Correct me if I'm wrong. Please. I have read the GNU literature. I may not completely understand it of course.

What does IANAL mean?

If somebody wants to use our code for free, then they have to obey the rules of the GPL, as this is the only free license we offer. This includes that if you distribute derivative work, you have to make the source code available, and allow distribution of your derivative work. Again, I suggest to check out the the GPL FAQ, this should answer your questions.

Originally posted by Werm
Extra Languages

So, what kind of access will you provide someone wanting to create another language binding?

How would you go about creating a language binding for a single-threaded language, or one where multithreading was not available/stable?

I don't think any additional form of access is required, since we already publish all source code for Ice. There are no hidden parts.

For a single-threaded language, I would suggest to use a reactive communcations model.

[Werm]

Classes

Cool. Will check out persistence, but to be honest I would think that most people already have a persistence framework that they use. Any distributed processing system I use will be on top of this rather than instead of it. But that's just me.


GPL

IANAL == I Am Not A Lawyer

What I mean is that I can't see how you can charge for the software (as opposed to distribution costs) and have it freely available under the GPL.

It seemed quite clear to me that you may charge whatever you like for access to the software, as long as that cost was no greater than access to the source. You can't stop someone from using it in a commercial setting though.


Access

I mean access with respect to submitting patches etc. Or do you not see yourselves integrating other people's bindings into your core distributions?

[marc]

Originally posted by Werm

What I mean is that I can't see how you can charge for the software (as opposed to distribution costs) and have it freely available under the GPL.

It seemed quite clear to me that you may charge whatever you like for access to the software, as long as that cost was no greater than access to the source. You can't stop someone from using it in a commercial setting though.

Since we hold the copyright for Ice, we can release it under whatever kind of licenses we choose.

We chose to release it under the GPL for free. Everybody who uses Ice under GPL has to obey the rules of the GPL. The GPL makes is clear that a program released under its terms is *not* pulic domain, therefore your assumption that somebody can do whatever they like with a GPL'd program is incorrect.

For those who do not wish to be bound by the terms of the GPL, we also release it under a commercial license, which has different terms, but is not free.

Originally posted by Werm

Access

I mean access with respect to submitting patches etc. Or do you not see yourselves integrating other people's bindings into your core distributions?

Which core distribution are you talking about? We have separate distributions for Ice for Java, C++, and PHP. There is no need to put everything into one single huge distribution.

[Ken Carpenter]

Werm, RE: GPL, Please do read the GPL FAQ reference that Marc suggested as you have grossly misinterpreted what rights the GPL gives you.

Really. Please read it.

[dthomson]

Would you mind if someone were to release a patched Ice with underscores allowed then? :-)

I would actually Have a look at http://www.zeroc.com/vbulletin/show...s=&threadid=84.

As I understand it, the ICE protocol is not patented, so anyone could just write their own C++ implementation that allowed underscores or whatever else.

However, you would have to feel pretty strongly about the issue to write an ICE implementation from the ground up.

If you would like to implement a language mapping, we would certainly support you in doing so! Note that somebody already started working on a Python mapping. Have a look at http://www.zeroc.com/vbulletin/show...hp?threadid=146.

I didn't know that - I must have missed this thread completely. I'll have to wander over and take a look/see if I can help.