Cool Solutions

Platform Support for Mobility Pack


April 30, 2010 3:45 pm





A little while ago Dean blogged on the Mobility Technical Preview here. There were a number of questions around our choice of platform support, so I wanted to spell out in more detail some of our decisions, as well as some of the roadmap.

For the first release we decided to ship it on SLES 11 64 bit only. There is a technical requirement for a newer version of Python than the one that ships in SLES 10, so we decided, for the time being at least, to go with SLES 11 only. To get Data Synchronizer to work on SLES 10 we need to include the version of Python that we required, which meant there were a couple of drawbacks:

1. There could be compatibility issues with other versions of Python installed on the server, or other applications that needed Python.

2. If we shipped our own Python we would also have to maintain it, including any security fixes. This means that if a security patch is needed for Python, and we had no Data Synchronizer patch planned, then customers would need to individually download and install the RPM.

3. The newer version of Python would not be included in the regular SLES updates.
We also decided to release this first version on Postgres. This helped us half the numbers of test cases that we needed to run. Adding another platform, or database, doubles the test cases. Adding both a platform and a database quadruples the test cases that we need to run. By simplifying the architecture we can release the product quicker.

Going forwards we will expand our platform support to include Windows, as well as other databases, like Oracle, MSSQL and MySQL. We need to confirm the timelines for these, and we may stagger support for each one – as I said we need to balance the platform support options with the time it would take to release the product.

The other question that arose from Dean’s blog was around the SLES entitlement. There was a lot of discussion around the OES entitlement to SLES, so I will clarify a couple of points. The current SLES entitlement in OES does include an entitlement to SLES 11, despite OES being installed on top of SLES 10. That entitlement, however, does not include the ability to run Data Synchronizer on top of it – it only covers OES workloads and services required to support OES users, like backup or antivirus.
In addition, Data Synchronizer is not a GroupWise component. Right now it supports GroupWise users, but, as the product moves forward, it will be licensed to work outside of the GroupWise space, so the GroupWise SLES entitlement won’t cover it either.

We have been working to include a SLES entitlement specifically for the Data Synchronizer product. That entitlement was approved this week. What that means is that Data Synchronizer customers will get a SLES entitlement for as many servers as are required to run the Data Synchronizer product. There are the standard caveats – the only workload on the server can be Data Synchronizer, and it is the core services only – so if you install some externally monitoring app it cannot consume the same entitlement (as an example).

I hope that explains things a little more clearly.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

Categories: Uncategorized


Disclaimer: This content is not supported by Micro Focus. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.


  1. By:tmstone835

    I also think that this should have been considered and dealt with beforehand instead of igniting a flame war on the blog.

    This seems to be a rather fragile situation on Novell’s part. Novell has been burned so many times for relying on third-party products and technologies to make strategic components and products that I thought you would make a truly home-built application. You obviously save money by not having to do all of that development but it must be nuts to try to test all of the possible variables using open source components. Maybe it isn’t any worse for you than dealing with undocumented Microsoft APIs but it sure seems like it to me.

    I also think that Novell needs to revamp the SLES/SLED component update process. Not being able to install Mobility Pack because of a Python dependency is what makes SLES administrators go nuts. I think Linux is great but dependencies are one of those things that are very frustrating. If Novell could solve that problem, they would have a huge benefit over the other distros. Hmmm…now that Novell has won the lawsuit with SCO maybe you could revamp Unixware and then you could control everything from top to bottom. I miss that.

    Oh well…wishful thinking.

    Tom Stone

    • By:aevans

      Thanks for the comment. We are not necessarily relying on 3rd party software here, but we do need a database infrastructure to support this.

      It doesn’t make sense to do a huge amount of heavy lifting to write a new one. In addition, as feedback from GMS will show, many customers want to be able to leverage their existing enterprise DB infrastructure – this is why we need to look at Oracle, MS SQL etc – this means they can use their existing knowledge and tools.

  2. By:FlyingGuy

    What is happening in Utah? Have you all just lost what little is left of your minds?
    Python!? PYTHON?!

    And not only Python, but a version Python that your Crown Jewel does not even ship with and we risk breaking a whole lot of stuff if we try to get to the latest version.

    You are writing what is arguably one of the most important bits of software you guys are doing in a language that does not have a block closure character? That changes at the whim of whoever the gang of idiots are that wrote this bad excuse for a language.

    You are the product manager, why, of please for the love of god WHY did you let some script kiddie talk you into writing this in Python? What were you thinking?

    You should have done it in Perl that way you would only have Larry’s idiocy to deal with.

    What are you trying to purposefully put yourselves out of business?

    How much SLES 10 SP3 is out there? How much of that runs GroupWise?

    “In addition, Data Synchronizer is not a GroupWise component. Right now it supports GroupWise users, but, as the product moves forward, it will be licensed to work outside of the GroupWise space, so the GroupWise SLES entitlement won’t cover it either.”

    So what you are saying is that you are abandoning including the ability to sync to our PDA ‘sas a fundamental part of GroupWise and at some point even if we buy GroupWise we are going to have to buy your fancy net new product if you want to sync our PDA?

    So Alex are you just Steve Balmer in disguise killing what is left of GroupWise and Novell from the inside out?

    So here is the deal pal. You do this and you can pretty much kiss GW goodnight.

    We have been keeping our clients, you remember those people right, on GroupWise by telling them, “Hey stay the course it is coming, its all good, it will all be integrated it will be seamless you wont need to buy yet more hardware to run different versions of the base OS” and believing we were telling them the truth, when in point of fact we have been lieing to them without even knowing it.

    Thanks a lot bud.

    • By:blntskul

      What exactly is it that you’re going post-nuclear about? The fact that Novell chose to use Python with Data Synchronizer? I think you’re overestimating Novell’s customers giving a ratt’s ass about the underlying programming language. If it works, we’ll be happy. I don’t care if they write it in VB.Net.

      • By:FlyingGuy

        Do a little research and look up the absolute stupidity there has been with Python from version to version. This has been an ongoing problem and has been hotly debated.

        I don’t know if you are a programmer or not but I am and the very notion of indentation being a block closure in code is just beyond stupid as it makes for very subtle, very very hard to track down bugs.

        Python is just yet another in the legion of C wrappers deJour that have been cooked up because new CS types don’t know how to write clean efficient code in C which is the language of *nix. They got their degree’s by going to a trade school and not a university and most of them would not know a JNZ instruction if it hit them in the face.

        The very idea that they would put out a product that will not even run on their currently shipping server product is absurd and whoever let this happen needs to be canned, yesterday if not sooner.

        This gives anyone who is still using GW all the more reason to just leave it behind, I mean not even MS is stupid enough to do this or has that much hubris.

  3. By:imc

    Wait a second, it’s not part of the GroupWise space? Does that mean my SLA, with GroupWise licensing, doesn’t cover this tool? Who’s idea was that? Correct me if I’m wrong, but Microsoft doesn’t even charge for activesynce on Exchange.

    The only users for this product, certainly up front anyway, are GroupWise shops getting this specifically to use with GroupWise. What else is anyone going to use it with?

    • By:blntskul

      What he’s saying is that the Data Synchronizer is not specific to GroupWise. It will be a product unto itself, used to sync lots of stuff to lots of other stuff. It will be a purchasable product. There will be a ‘Mobility Pack’ version of it that includes **FOR FREE** to GroupWise customers, the GroupWise connector and Mobility (aka ActiveSync) connector. He also said that the SLES11 entitlement will be included for the solution.

      So, to be clear, if you’re a current GroupWise customer, you will get the entire solution to sync GroupWise to any ActiveSync compatible device for free, except for the hardware of course.

      • By:imc

        That’s what I wasn’t clear about, whether or not I was covered as a GroupWise customer. Thanks for clearing it up.

  4. By:blntskul

    I read your post again to try to understand why you’re so incensed. Is it that you’re going to have to have a separate server to run the solution? If that’s the case, are you aware of the previous solution that everyone was happy with? GroupWise Mobile Server is/was a Windows product, and required its own server. If your system is so small that this presents a big challenge, just run it virtualized on whatever piece of junk you can muster. You don’t need a big expensive server, particularly if your user base is small. If your user base is large, it warrants the requisite dedicated hardware or virtual server. Even in Exchange world, you’re supposed to separate those components onto different servers for performance. Only small customers run everything together.

    Regardless, Novell made the right choice in building this out to be more than just a GroupWise to mobile phone solution. Many customers will see the wisdom in this direction.

    • By:imc

      blntskul, even before any details were known about the product, I just assumed it was a separate server. I’ve got GroupWise spread out over 8 servers now. So no, that’s not an issue for me. My post was really about the misunderstanding of the licensing costs for GroupWise customers which you cleared up for me.

      • By:blntskul

        I must have goofed on my reply. That was actually a reply to FlyingGuy’s post. You didn’t appear to be incensed at all. My apologies.

    • By:FlyingGuy

      Ok, So what am I so incensed about? Well in no particular order:

      • SLES 10 SP2 is the shipping product that runs OES and everything else. Nothing else as far as I know is certified for SLES 11. So I get to have yet another variant in my shops.
      • The fact that this is not a GW exclusive solution means GW is going to get flopped in with all the other things they are going to try and do with this as far as bug fixes and enhancements go and the GW team is now subject to the whims of whomever ends up running this.. Lets put yet another nail in the GW coffin shall we?
      • I have a lot of small shops that run Novell in single server implementations where one substantial server ( think Dell 2900 or T610 series ) runs the entire shop from F&P to the GW system AND acts as the firewall to boot! These shops would benefit from having an all in one server. But because someone someplace made the insanely stupid decision to write the blasted thing in Python AND a version of Python that is not supported on the version of SLES that they ship the NOWS and OES system on, Novell loses, I lose business and in my not so humble opinion my client loses .

      I am beginning to feel as though GW is quickly becoming the bastard step-child of Novell that they cannot afford to walk away from but they cannot afford to really put the work into making it the world class solution is has the promise to be.

      So yeah I am incensed. I keep seeing the product quality get worse and worse and the efforts to make it better seem to get less meaningful every time I turn around. If there is some grand strategy here that has one very sunny horizon then they had better articulate it because it is getting harder and harder to get clients to hold the line.

      • By:blntskul

        I guess all I can do is just generally disagree with your outlook. I see constant improvement in GroupWise, and Novell has reiterated as strongly as they can that it’s a strategic platform for them for years to come. When non-biased people stack up GroupWise next to Exchange and Notes, it’s feature set is very competitive, and it’s cost to buy, own and support are superior. Novell continues to decouple products from their sole dependency on Netware and eDirectory, and you’ll see GroupWise make inroads into more markets because of it, not fewer. GroupWise running all on Windows with Active Directory some day will make it even more competitive. They’re not planning to drop it. They’re planning to make it easier to adopt.

        As far as the platform issue goes, it doesn’t have to be such a major concern. Run it on the cheapest workstation you can find, or on an existing workstation running VMware, if cost is a big problem. For your small shops, it’s not going to be that demanding. Larger shops should expect to scale outward. Personally, if I were setting up a solution for a small business, even if it’s a single server solution, I’m building it on top of a hypervisor – VMware for me. Even if it’s a one guest OS to host server ratio, the benefits of virtualization are many, and would mitigate this kind of issue.

        Finally, if your customers are that small and/or cash strapped, just wait it out. This solution will eventually be supported on your platform. They’re trying to get it out quickly, and most of their customers will be able to take advantage of it despite your concerns. For the short term, use Notify or something. They’re aiming at the larger group of their customers for now, and they’ll catch you up later. If you freely admit that you’re problems are mostly due to small customer installations, you should appreciate that the first target group may not be yours.

      • By:aevans

        We expect customers in the small business space, those with less than 10 – 15 devices or so, to not really want roll out something like Data Synchronizer for their devices. This is where Notify, and their hosted service, fit the bill perfectly. For those slightly larger customers VMWare does fit the bill.

        Also, thanks for pointing out that, whilst initially we are limiting platform support, we do plan to expand to other platforms in future releases. We are taking the limited approach so that we can streamline our efforts, and create the Mobility Pack experience – rather than expecting customers to install each connector manually.

  5. By:tmstone835

    I am starting to think that a native GoupWise connector client for iPhone and Blackberry is a better way to go. Since this ActiveSync connector is not turning out to be a simple product or implementation, I question the value of implementing a serious piece of software and hardware compared with other methods. The cost may be justified for 100 or more devices but it still doesn’t work for a small to medium sized business. What is maintenance going to be like? How reliable with this solution be?

    How hard would it be to write a native connector or client for Blackberry or the iPhone? Am I asking for the impossible? Novell did all of that Java work in the Native Clients. Could that code be recycled?

    • By:blntskul

      Native clients don’t really make sense these days. The defacto standard for portable device sync is Activesync Protocol. Could it be done better? Of course. Microsoft has never been the pioneer of the best solutions in any case. But that doesn’t matter. Your phone and phone OS manufacturers have set the stage. They pretty much all went this route, except Blackberry, who remains proprietary. Novell would be in a uniquely bad situation to have to maintain code specific to all of those platforms. That’s how Intellisync (aka Groupwise Mobile Server) worked, and Nokia dropped it when they already had the solution. It was clear that there was no future in it.

      The best thing would be for all phones to support it and all groupware products to provide it, and make it better collectively. Nothing really compares to how well the Blackberry solution works end to end, but they’d better not rest on their laurels.

      • By:aevans

        I think we should just make you the official spokesperson – could not have said it better myself.
        To expand a little on some of your statements, we have a global consideration. Whilst iPhone and Blackberry support might suffice for the US market, it would be woefully lacking outside of the US. Nokia has 90% market share in some European regions, and Windows Mobile is disproportionally strong in the Asian market – also not forgetting that Android is a serious up and comer, and the HP purchase of Palm could well add more strength to the Tablet market. We need to support them all, and the path of least resistance, as well as the one that makes the most sense strategically, is the one that we are doing.

      • By:tmstone835

        It seems as though this single purpose simple solution of an Activesync connector that germinated over a year ago has morphed into an ugly giant that now requires a 64 bit kernel, your proprietary leading edge operating system, possibly separate licensing, and a complex installation. I can appreciate the desire to have an all purpose GroupWise connectivity and synchronization tool but this isn’t what any of us envisioned. We thought you were making an Activesync gateway. That’s it. Nothing more. Single purpose. Lightweight. I think you get the picture.

        I may want a great wrench but I do not want the raw ore, the refinery, the steel mill, and the manufacturing plant along with it.

        Maybe I am not seeing the big picture here.

  6. By:blntskul

    The technology preview is available for you to download and try out. It’s not a big beast, nor is it difficult to install. Why is it a problem to require their own 64-bit operating system? Novell requires their own OS for several of their applications. They don’t support every distribution out there to run their products. Everything Microsoft releases requires their own operating system, and Windows Server 2008r2 only exists as 64-bit. That’s a pretty good indication of where the market is going. Alex stated in this blog that the SLES licensing will be covered at no cost.

    You want a simple GroupWise to ActiveSync gateway. Even if they didn’t have plans to make it more than that, the basic design and development effort would likely be the same, and likely take just as long. What you’re getting in the Mobility pack is a GroupWise SOAP connector, a conversion engine, and an ActiveSync connector. A simple GroupWise to ActiveSync only solution would consist of the same elements. Maybe they wouldn’t be labeled as such, but they would still be there under the covers. The fact that more connectors are going to be developed doesn’t complicate the Mobility Pack. The things that make up the Mobility pack are being developed first, and are the priority.

    If you’re a company that only uses GroupWise and mobile phones, you may not appreciate the vision behind this product’s design. If you want to sync more than just those two things, or maybe things that don’t include them at all, you will appreciate it.

  7. By:kkbass
    For those of you who were concerned about the licensing, it looks like if you have the full version of vmware esx then you should be getting a free copy of sles for each license. So for a non-novell license resolution to this, it would appear this settles the debate, however those still using the free ESXi would not qualify for said offer.

    • By:blntskul

      Alex said that they’re going to cover the required SLES licensing for GroupWise customers. He didn’t qualify it with VMware. Hopefully that partnership isn’t related to Mobility Pack licensing. That partnership is a great idea all on its own. Great news Novell!

    • By:ecyoung

      “VMware vSphere 4.1 will be generally available in 3Q2010.”

      That’s the first solid date for vSphere 4.1 that I’ve seen. Interesting that VMware would leak that info like this.