Thanks for all of your interest at Spectrum. I appreciate all of your
feedback and am making adjustments.

PavukIDF is now offered in 2 versions:

Enterprise - deployed on OS X Snow Leopard Server
Standard - deployed on Linux. Presently testing with Fedora 12/13
beta

The primary difference is that Enterprise is designed to integrate
into Directory services for cloud computing for large systems. Please
see Apple's website for all of the information on OS X Server (that
they don't advertise!)

***

OpenQM is now bundled with Pavuk to make your purchasing easier.

Enterprise: $289/user including QM. $30.00/user/year maintenance and
upgrades.
Standard: $249/user including QM. $25.00/user/year maintenance and
upgrades.

Upgrading from Standard to Enterprise is the difference in the retail
price.

***

There will be a new rendering engine in Pavuk 2.0 using the ExtJS
library. This will dramatically increase functionality and should
provide much better support for iPhones and iPads than the present
ActiveWidgets JS library. Expected shipment of Pavuk 2.0 is June 1.

Bill Crowell
Pavuk Technologies, LLC
+1 704.248.0024

On Apr 19, 8:45*am, Bill Crowell <bcrow... (AT) pavuk (DOT) com> wrote:

No explanation of what PavukIDF is.

No website links.

Is this a technology exclusive to those that attended Spectrum?

--
Kevin Powick

On Apr 20, 8:06*am, Bill Crowell <bcrow... (AT) pavuk (DOT) com> wrote:
Out of curiousity, how many people DID attend?

I haven't seen any real mention of Spectrum ... apart from the
weather ...

Hmmm, Pavuk supports QM only and doesn't support IE or Firefox. That
narrows down the market to a precious few prospects for developers and
further for end-users. I look forward to seeing this product when
it's had some time to brew.

From the website: "Because of the unpredictability of the reliability
of IE’s Javascript interpreter, the use of one of the officially
supported browsers is highly recommended."

IE's Javascript interpreter isn't unpredictable nor unreliable.
There are nuances which make IE/JS process code differently than other
platforms. That said, those issues were largely in IE5/6. IE7 went a
long way toward fixing the problems and IE8/JS seems to be as stable
as any other. With JQuery, coding differences between browsers in
terms of JS and CSS have largely gone away.

"There is nothing wrong with having more than one browser program on
your computer!"

If you think about the reasons why people prefer thin client to thick,
one of the main reasons is to reduce client-side administration. We
do that by using a "universal" client rather than installing and
updating thick-client applications. If a company needs to install yet
another thin client just to support another application that concept
sort of goes out the window - we might as well be using thick-client
apps.

And about thick-client, while no one has asked me for a thick-client
compared to a browser app in at least 5 years, I will also note that I
haven't heard about client PC app administration problems in the same
amount of time. I believe this is largely in part due to the
acceptance of self-updating software, something that people took a few
years to get their heads around. Most of the software we install
these days is self-updating or at least polls a server to let you know
that an update is available so that it can download and re-register
itself. Maybe it's time for people to re-think why they don't want to
install software on PC's anymore - considering even the people who
code for browsers are asking us to install different browsers just to
accommodate their preferences.

T

On Apr 20, 9:13*am, Tony Gravagno
<address.is.in.po... (AT) removethis (DOT) com.invalid> wrote:
They don't? I do. IMO, browser-based applications have functionality
that limits them to specific applications. Just because we see
everyone trying to cram their applications into the web browser space
doesn't make it right.

Developers like browser apps because it largely removes deployment and
updating issues. One aspect of them that consumers like is instant-
use "portability"; You can run your application on any computer.

These are compelling reasons for a browser based approach, but should
not be the only reasons for going down that development path.

--
Kevin Powick

Actually, in my limited exposure to "big business", one of the reasons
that many CIO's DON'T like people installing Firefox (FireFix?) is
because it IS self updating, and in the blink of an eye they can have
1000 workstations updated to the latest version of Firefox before they
have had the opportunity to test, and ... you guessed it, things can
(AND DO) break ...

For all the bagging people give Microsoft, one of the things that I
believe the big end of town REALLY LIKE is the ability to control the
flow of updates via domain rules and a (couple of) internal WSUS
server that only provides AUTHORIZED updates

YMMV, but I suspect that the bigger you are the more controls you need
to have in place


On Apr 20, 11:13*pm, Tony Gravagno
<address.is.in.po... (AT) removethis (DOT) com.invalid> wrote:

<snip>

On Apr 20, 7:51*pm, Ross Ferris <ro... (AT) stamina (DOT) com.au> wrote:
Taking the points in order:

Pavuk is deployed on QM and, for the moment, only on QM. There are a
large number of technical reasons WHY it is done here. The technical
issues of deploying really universal, cloud computing applications are
numerous. Let's look at some of the key features in QM that facilitate
a web-based approach:

1. QM supports binary data streams enabling the creation of a purpose-
built web server. One of the keys to the success of how Pavuk is
easily deployed and ran 305 users quickly and efficiently was the lack
of the need to coordinate a vast chain of components just to bridge
into Apache or IIS. Martin has written a number of functions critical
to this end. While not web 2.0 in this version, it is much better than
web 1.0 call it web 1.5. As to Tony's point about testing, we've run
it for nearly a year with real end-users running a medical application
on a CC/SaaS system.

2. QM has native support for the *nix Epoch values as well as full
support for the Olson timezone database. This enables the projection
of users and accounts to be in their own time zone regardless of the
server's location. We're no longer parochial to a server. I can have a
user in Bratislava, Slovakia and their time stamps are just as
meaningful as a client in Los Angeles and reflect similar. You simply
cannot work from static offsets from UTC. You have congress changing
DST and it messes up the works for us all.

3. QM also is binary clean. I can process binary attachments directly
in the same data stream with the text data. No tricks are needed for
upload, download.

4. QM is extremely fast.

5. Rocket Software was in my booth making a full-court press for me to
port to UV. Would they be willing to enable me to connect without
having to use UniObjects or some other byzantine method. One thing
about Ladybridge, they help you sort things out and work with you. I
value loyalty and outstanding customer service from Ladybridge.

Next for the browsers.

Browser JS incompatibility issues are widely known. IE is well
documented as being the very worst offender. I have a number of users
telling me that their particular combination of IE and Windows works
just fine. I have an equivalent number say that it does not. Why
should I, or any other developer, lock ourselves into the whims of
what crap comes out of Redmond? Should I spend precious development
time each time there's a new bug in IE?

As you see on the page where I show the tested and supported browsers,
they are all reasonably compliant with W3C and standard JS. They work
well. They're accepting the same stream. Firefox, Opera, Safari,
Chrome, all work very well. If they do, why doesn't IE if not for bugs
in their JS interpreter?

With V2.0 due in June, the rendering library will be ExtJS. They have
much broader browser support than any of the other libraries. They're
built on YUI. Simply changing to this JS library will bring better
rendering support for more browsers and versions of browsers. ExtJS is
supposed to adjust to most of the browsers. Most probably, IE support
will be better in V2.0 just because of ExtJS.

The goal of Pavuk is to support as many devices as possible. The best
way to do this is to stick with the standards of whatever connectivity
is being used.

Next, the servers:

Apple has not done a good job of marketing their OS X Server. It's an
outstanding product and ideal for cloud computing and administering a
large number of users, permissions, distributed storage, etc. The
problem is that very few know about it.

Hence, we have a Linux version forthcoming. This will enable the
relatively smaller MV users to have the benefits of Pavuk while still
enabling the enterprise clients with whom I'm in discussions to plug
the OS X server into their existing AD network and use central
administration for 1000s of users. You now have a choice. With over 15
years in Linux, Pavuk was originally developed there. It was moved to
OS X server for a large, cloud project.

Cheers!

Bill