Also, I found this post on the Yahoo board about Puma, Puma's strategy,
and Puma's competitors. Since this is an "investor" message board
there's probably a decent amount of cheerleading in the information
below, but at least it gives you a feel for what Puma is presently
trying to do...
> by: RandomHike (35/M/S.F. Bay Area, CA) 12/29/99 2:50 am
> Msg: 7081 of 7087
> What PUMA offers to the wireless sector....
> PUMA creates software that allows wireless Smartphones and Personal
> Digital Assistants (PDAs) to receive specifically requested data from
> the vast amounts available on the Internet, corporate Intranets, and
> back-office databases. PUMA's software also allows new information to be
> entered into these data sources. The two PUMA products that provide
> these services are called "Intellisync" and "Satellite Forms." They are
> commonly referred to as sychronization software.
> These software products are and will be useful since small mobile
> devices do not have the capacity to store or means to view large amounts
> of data on a real-time basis. The software allows the user of mobile
> devices to access only the small amount of data that is of interest.
> PUMA's software is purchased by Fortune 1000 companies, Internet
> companies, Smartphone manufacturers, and consumers:
> There is competition that has similar software (Extended Systems,
> Riverbed, and Motorola's Starfish), but PUMA markets its software
> differently AND has recently acquired two new companies (ProxiNet and
> NetMind) that add value to the original PUMA product...value that the
> competition does not offer. Also, PUMA is offering Intellisync.com as a
> "centralized" portal for simultaneous synchronization with several
> different sources of data on the Internet. I will elaborate further on
> these points:
> 1) PUMA markets its software via Software Development Kits (SDKs),
> unlike its competition. The kits are sold to clients' IT departments
> which use them to easily develop a custom-designed synchronization
> application. The SDK route is cost-effective and a user friendly (e.g.,
> "shrink wrap") approach to selling custom software....and it's scalable.
> Scalable in this case refers to a software product that can be
> mass-produced and quickly marketed with essentially fixed overhead,
> resulting in a widely distributed product. Thus far, approximately 50
> Intellisync SDK licenses have been issued.
> 2) PUMA's acquisition of ProxiNet provides the company with software
> that allows mobile devices to view web pages in their original form,
> complete with graphics and cookies. Today, web content providers must
> redesign their web pages so that they can be viewed as text (not
> graphics) on a WAP-based mobile device. Since ProxiNet's technology does
> not require web content providers to redesign their original web pages,
> it is expected that Internet companies and corporations with Intranets
> will eagerly purchase this server- based software (called "ProxiWare").
> 3) PUMA's acquisition of NetMind gives the company the technology that
> allows a specified change in a web page to be reported directly to a
> mobile device user. For example, if you want to know if your bid price
> for an item on E-Bay has been outbid, NetMind technology will send an
> alert to your Smartphone or PDA.
> 4) The introduction of Intellisync.com (scheduled for the first quarter
> of 2000), will allow a user that synchronizes data from multiple sites
> (e.g., AOL and Amazon.com), to simply visit Intellisync.com rather than
> both sites.
> ....and finally one more point, NO ONE offers this range of services
> today. PUMA should be offering it all by the later half of 2000.....in
> sync with the higher speed wireless offerings of Sprint PCS (with QCOM's
> cdmaOne technology) and Metricom (with its Ricochet2 modem). By the
> Summer of 2000, both companies will provide wireless services at or in
> excess of 128 kbps on a nearly national basis. PUMA's services will
> (IMO) fold right into this grand plan.
Compared to other systems that support synchronous groupware, our design
is unusual in choosing to have centralized state but providing as little
processing at the server as possible. We find that centralized state is
simpler for any groupware that involves more than two parties,
especially if there can be late arrivals to a group already in progress.
Indeed, for the class of applications we call "awareness" [Patterson et
al. 96], some centralized state representing a group's membership is
necessary because the identities of the other parties only become
apparent upon joining the group, and members may join or leave at
arbitrary times. Even a system such as GroupKit [Roseman and Greenberg
96] that is nominally based entirely on peer-to-peer communication has a
centralized portion to deal with awareness. A further advantage of a
centralized system is that locking is simpler.
We leave Thing values uninterpreted, and otherwise attempt to minimize
server processing for two reasons: scalability and reuse. As noted
earlier, the general principle of pushing functionality out to clients
whenever possible has been well-established in the distributed systems
community [Howard et al. 88]. In addition, we have seen that our minimal
constraints on the structure of Things make it easy to adapt a
notification server for a wide variety of applications.
Initially we were quite insistent that the role of a notification server
was to share state, albeit ephemeral state, in distinction to multicast
services such as Zephyr [DellaFera and Eichin 88]. Over time, we have
come to realize that shared state notification and multicasting of
messages are complementary, and that forcing multicasting into a
framework of shared state is unpleasant. Accordingly, we added notices
to the protocol. A broadcast notice is sent to every client present in a
given Place; a targeted notice is sent to a specific client, as long as
that client is present in the Place. Both kinds of notice are treated as
notifications in terms of the protocol. With the addition of notices, we
were able to eliminate a category of message called alerts, which had
been defined for the purpose of conveying server-related information to
clients. The addition of notices has opened a rich collection of
possibilities for controlling and communicating with the server, since
the sender or recipient of such a notice can be a pseudo-user actually
representing some part of the server.
-- Day, Patterson, and Mitchell, "NSTP", WWW6 Conference,