| |
SAP has chosen Visual WebGui for strategic web application, Mr. Saar of SAP explains why in an interview with with Jeremy Geelan at AJAX World.
Click on the video image to watch
|
|
|
|
|
|
|
 | SearchForum Home | |
| | |
| | |
| | |
 | | |
|
|
|
| Re: Licensing, Per-Domain, and early adopters |
|
|
Hi Again,
HappyFirst:
So I'll keep on answering :)...
* LGPL entitles you of free deployment unless you extend the library. Extending the library enforces you to share the code...
* One server is a standalone server, you can deploy as many as you want without scalability server which provides floating session to support a non-session-sticky solution. Scalability server is a premium.
* Early adopters get to use and deploy under LGPL any of the controls that were within the basic SDK before they have joined. Those would be some controls from the office extension such as the schedule-box and the navigation-tabs.
* Visual WebGui is not controls library, the deployment and runtime model is rather unique and this is where the registered patent is on within VWG. That is why VWG premiums are charged by deployment and not development.
* We are currently re-considering the royalties model, however, until a new decision will be taken, the model is as I have described.
Regards,
Itzik Spitzen |
|
|
|
| |
|
|
| Re: Licensing, Per-Domain, and early adopters |
|
|
I'm glad you have laid out what you mean by LGPL; that's the correct interpretation of that license, as I understand it. I have seen some companies muddle the meaning in exactly the way that people in this thread were concerned with (does the app have to be shared; no, only exentions to the library). The writeup on this website *is* not clear; it'd be good for all of us if it could be clarified.
One thing that might help alleviate confusion over the VWG license would be the creation of a page that posits a robust set of scenarios that developers are likely to be involved in, and how the current license would play out for each. Someone like HappyFirst or myself would be able to map our situation over to one or more of the scenarios and determine in an uambiguous manner how gizmox would expect the licensing to play out. We would probably ask you to add some alternate scenarios to the original set you create; you'd learn more about your users, we'd have surety regarding what we're getting in to. Our suggestions would be more precise, because we'd have a better understanding of how the current licenses could impact us.
It would be interesting to have some insight into what kind of load a single server can handle. You could present this information via stats on a test application that everyone could become familiar with, on a singer server, under test or even actual use?
I am also somewhat spooked about VWG licensing at this point. In the early days, when guy was a frequent poster here in the forums and did most of the tech support, the fiscal model for gizmox seemed to rotate around selling support and add on products. It has not completely deviated from that, which is good, but the licensing scheme is way more complicated that I expected, and goes into territory that I had not anticipated. I hope it works out for everyone, and I think it will.
I wish you guys would fix this forum software, the word wrapping problem and other issues persist now for a very long time |
|
|
|
| |
|
|
| Re: Licensing, Per-Domain, and early adopters |
|
|
Hi Michael,
We will seriously consider publishing scenarios with their licensing next to them, this seems like a very good idea!
A single server can hold between 200-400 concurrent users depending mostly on the machine straight.
* VWG almost eliminates the limitation in terms of CPU usage due to the fact that it does not construct and destruct objects/controls rapidly as ASP.NET.
* VWG consumes only a small amount memory on the server more than ASP.NET (between 1-10Kb per user) in order to keep a local copy of objects model alive on the server when the application is running.
Notes:
* When using server capabilities extensions such as communication server, one server will support fewer users since it handles requests more tightly.
* Your BL and DL can enforce you to deploy on more than one server due to other load limitations (non-VWG considerations).
I'm not sure that I fully understand your last sentence regarding the licensing model, however, we are still considering it and it is still subject to change. As for Guy, he is too busy with architecture and making VWG a thorough solution for web applications as we see it :))! Believe me that bottom line he is working hard for you guys :)
Regarding the forum, it's in did a painful subject, we know that it sucks, however, we are considering to upgrade our DNN version to 4.xx and .NET 2.0 (currently it's 3.xx with .NET 1.1), the process is not that immediate due to the fact that we have some extension modules that are not smoothly upgrade-able to the new DNN. I promise you guys we will handle it as soon as possible!
Always willing to get feedbacks from you guys!
Thanks,
Itzik Spitzen |
|
|
|
| |
|
|
| Re: Licensing, Per-Domain, and early adopters |
|
|
Itzik, in your previous posting your mentioned that gizmox is reconsidering it's royalties arrangement; but I don't see mention of royalties on the commercial products page? Do you mean the OEM licensing?
Can you explain more about OEM licensing? What exactly is an OEM deployment to you? Say I develop software using the basic dhmtl VWG. I find five companies that would like to use the software. Can I simply install the basic vwg framework on the five company's servers, or am I somehow obligated to license from you as OEM?
Another way to put it, if one is using only your basic product, at deploy time, when if ever does one cross a line which would require any licensing other than the free as in beer?
I'm not saying that a primary objective is to avoid licensing from gizmox; but I do want to know where the lines are, in advance.
What I meant by the old presentation re the expected licensing model which Guy used to offer when asked, was that I expected gizmox to eventually offer paid support, and then something like an extension for clusters etc. It's much more complicated than that now, with "royalties" and OEM licensing and controls in separate packages with per domain licensing (I think). It's hesitation-making <g>.
One other bit that HappyFirst brought up was the early adopters grandfathering issue...it's still confusing, how that will work, isn't it? Aren't the grandfathered controls mixed in with non-grandfathered controls in the extension you offer? I'm not sure, just an impression I gathered. |
|
|
|
| |
|
|
| Re: Licensing, Per-Domain, and early adopters |
|
|
Thanks for the reply, Itzik. I just want a little more clarity on one specific point. You say early adopters can continue to use those controls that moved out of the basic SDK for free.
Is that free for ONLY ONE domain or as MANY domains as they need? |
|
|
|
| |
| | |
| | |
| | |
| |
|