From: Jeffrey Kay (jkay@ENGENIA.COM)
Date: Mon Jun 19 2000 - 22:52:37 PDT
This must be the hot late night chat topic!
Greg -- thanks for the intro! Ken, I don't believe that we've met before.
Are you in the DC area?
Most of Greg's comments below are correct (thanks for the compliment, Greg).
Our Unity product is really more than just a web portal. It's fundamentally
a collaboration system with a web portal presentation interface. The
"Personal Edition", the freebie that you've been playing with, is really the
same product as the workgroup edition with a slightly different
installation. When Unity is deployed, it acts very much like a peer web,
allowing desktop nodes like the personal edition to connect to other nodes,
desktops and servers. We do this to make the user feel like everything they
access is on their desktop, whether they are on-line or off-line. The only
real distinction between a server and a desktop (same codebase, really) is
the roles that each plays in the peer web. A server can act as a 3rd party
repository for activities, people, etc, allowing for 24 x 7 access to shared
information. The replication/synchronization feature of Unity allows a user
to create a replica of any Unity object that is on any other system, either
server or desktop.
As Greg described, our object model is built on XML and JavaScript (there is
no Java or ActiveX in our software). We chose JavaScript so that we could
host Unity easily on any number of platforms; our code includes a JavaScript
interpreter inside. As a matter of fact, we're just about done with our
Linux version of the code. Our Unity object model extends JavaScript to
support inheritance, polymorphism, and other such geeky programmatic
constructs, but we also chose JavaScript because there's a pretty large base
of users who know how to build things with it. Our use of JavaScript is
similar to Netscape's SSJS, if you recall that. JavaScript functions of a
Unity object are directly mapped to URLs, so they can be called directly
from a browser. In many ways, Unity is really a small, JavaScript-based,
XML-based web application server that lives right on your desktop. The XML
part of our object model is used to define the structure of a Unity object
-- properties, relationships, security policy, and the like.
One of the more interesting constructs in our system is the Relationship
Web, a way of defining persistent, links between Unity objects. We use this
to identify a person that implements a task, a group that includes a person
and the like. In the Unity user interface, this is most readily apparent in
the "Map" view, where you can see the relationships that a given object has.
This gives an object context, essentially neighbors to work with. We use
this to establish simple workflows, send notifications, as well as define
semantic relationships between elements. All of the relationships, as well
as properties, are serialized into XML as part of a Unity object definition.
Each Unity object is a singleton, identified by a GUID, the serialized XML
and a collection of ancillary and document files (basically elements too
unwieldy to put in an XML stream).
The beauty of a model like this is that we can support replication very
nicely with it. Since Unity objects are our core elements in the system,
that's what replicates. You can pick an activity or a group and replicate
it to your desktop and run off-line. If an object has JavaScript code in
it, it'll replicate and run off-line just fine. None of the business rules
for Unity are in the core executable; they are all coded up as Unity
objects. We even support the notion that an off-line replica may not
support all of the functionality that might be available on-line.
We currently generate web pages using JavaScript formatting, but all of that
code is sitting in a collection of Unity objects that are entirely
replaceable. I've been spending some time working with building a
collection of Unity objects that will generate pages appropriate for
handheld devices as well as generating VoiceXML. These are all relatively
straightforward tasks in Unity, as is the possibility of generating XML/XSL
based pages.
We licensed RSA and signed up with Verisign so that we could support SSL
connections between Unity nodes as well as HTTP/S to the browser. We
currently don't support WebDAV, but it's on the books for our next go around
on the code. We opted first to build file system hooks and filter drivers
for Windows to allow Unity to directly emulate a file system within Windows.
This works both locally and remotely (we make everything appear local to the
user regardless) and will allow you to use virtually all of your Windows
apps directly with Unity. Presuming you're running on Windows 9x or NT (we
didn't ship with a Win2k driver -- coming in about a month), you can open
MS-Word or whatever and do a "Save As ..." directly into Unity. Any app
that supports common file dialogs also works.
Unity doesn't really require a centralized server. We package the software
that way (marketing decision), but in fact any Unity node can talk to any
other Unity node. We have a few additional functions that we'll expose in
the next release that enhance that capability, but the basic idea was to
support everything from a centralized server to a Napster-like centralized
rendezvous to a Gnutella-like web. Most of our target audience is currently
thinking "workgroup", so that's what the packaging looks like today. When
we deploy in a workgroup, every desktop and one server gets a Unity node
(essentially what you have in the personal edition). The desktops are
configured with the location of the server, and now anyone can collaborate.
The web pages that are generated for a desktop come from the desktop node,
not the Unity node on the server. You can web directly into the Unity
server, but then you lose out on the replication/synchronization as well as
the direct support for Windows apps.
One of the keys to our model was the development of the Unity object as a
programmable entity. Anyone can build a Unity object; the easiest to build
are the panels that appear on the web pages. Each of those is a separate
Unity object and new ones can be easily developed and added into the system.
For fun this evening, I developed a Unity object that will load one of
Microsoft's WebParts into a panel. I did a little testing with the WebParts
on Moreover.COM and everything worked with about 25 lines of JavaScript. To
really complete the job, I'll probably need another 25 lines of code or so
to add a configuration interface. The code uses our built-in URL JavaScript
class (which opens up a web link and reads the content) as well as our XML
JavaScript class (which can process any inbound XML). Using this component,
any end user can download and install a WebPart right on their own desktop
-- no server-based portal required.
A key philosophy in the system is to work at a level higher than files and
folders. As one of my UI design colleagues put it, users spend a great deal
of psychological energy on two problems -- first, how do I find a file that
I just created a little while ago (two hours, two days, two months ...) and
second how do I name a file so that I can find it later to avoid the first
problem. I don't claim to entirely solve that problem, but I think that
we're beginning to scratch the surface a little with Unity. Unity organizes
more sensibly by project, group, activity, person, and each of those
entities is a collaborative space where you can park documents, notes, etc.
If you and I are working on a collaborative standards effort, you and I will
likely each be related to this standards activity in Unity, thus showing it
on our home pages and giving us a place to do our work together. The
Relationship Web that Unity allows you to create gives you a
non-hierarchical means of associating yourself with the things that are most
relevant to you. No more hierarchical directory structures needed --
organize your stuff as you see fit. And even so, you can still do a "Save
As" directly into Unity.
In terms of going to market, you know that we've produced a CD with the
software on it. We ship it through distribution channels to VARs and
systems integrators. We're currently working with several of these types of
companies as well as some development partners. I'm always on the lookout
for new partners.
Currently, I'm interested in as we move along here is standardization.
We've adopted some technologies that are already standardized and we've
implemented our own version of a couple of things that might be standardized
(our XML-based RPC, for example). Now that we've got a first go at our
product, I have some time to work with some of the existing working groups
on how we might help each other push towards good standards for everyone.
Just to give you a little background, Engenia is a breakaway from IBM and
Lotus. The founders of Engenia (I'm one of them) decided that we could
build a better collaborative system by taking advantage of many popular
Internet technologies and wrapping them into a new form. We've moved a web
server onto the desktop, provided an infrastructure that speaks HTTP, IMAP4,
POP3, SMTP, and XML, and build an extensibility model that is programmable
in JavaScript (you can even open up a raw socket). In addition we've build
a layer of node to node communications that transparently allows any Unity
objects to talk to each other. I believe that our system eclipses any
collaborative system on the market and will be an awesome framework for
managing knowledge work. Unity's Relationship Web will add tremendous power
to the mix, essentially defining the context and profile of any given Unity
object in the system; this will allow us to add capabilities in the system
for pattern matching collections of Unity objects. We've done plain
installations of Unity as well as built entire strategic management systems
using it -- it's a capable platform.
I hope this helps explain what Unity does -- feel free to contact me with
any other questions and I'd be happy to go into greater detail with you at
your convenience.
Jeffrey Kay <jkay@engenia.com>
"First get your facts, then you can distort them at your leisure"
-- Mark Twain
"Golf is an endless series of tragedies obscured by the occasional miracle"
-- Sports Illustrated
> -----Original Message-----
> From: Gregory Alan Bolcer [SMTP:gbolcer@endtech.com]
> Sent: Monday, June 19, 2000 11:49 PM
> To: Meltsner Kenneth
> Cc: fork@xent.com; Jeffrey Kay
> Subject: Re: Engenia portal: MyYahoo + Magi....
>
> That's so funny...it's such a small world.
>
> We met with the Engenia CTO last month in Chicago for a comparison
> of approaches. They've built an XML object model on top of a
> personal portal engine. Jeff is extremely knowledgable about
> XML and has created an XML object model that supports the hooks
> and views. One of the problem with Engenia is that it's so
> flexible that in order to put a policy in place you need to
> fix a policy first. They are just now entering into their very
> first sales cycle, it'll be interesting to see how well received
> they are.
>
> One of the differences of philosophy I had with Jeff was how
> they go about doing their metadata. For their collaboration
> we use WebDAV, they use their own XML object model; for objects
> we use standard Web resources and different language CGI
> scripts/servlets, they use an object engine with
> methods, state, and inheritance implemented in the XML
> model. For GUI, we use XML/XSL, they use java and javascript
> formatters. They've gone the extra mile to put in their
> personal portal views project managers and security certificates,
> we've gone the extra mile to make sure we are always open
> source and latest protocol compliant.
>
> Anyways, maybe he'll pipe in and talk about their disconnected
> and synchronization features.
>
> Greg
>
> "Meltsner, Kenneth" wrote:
> >
> > I've been playing the new Engenia Unity portal product. So far, I've
> only
> > used the personal server version (brings up a webserver on your local
> > machine and serves up pages just like its big brother, but without file
> > sharing and other collaboration tools).
> >
> > The feature set looks like most portals: a front page with lots of boxes
> > with info from various sources. There's support for defining multiple
> views
> > of your life (e.g. work, family, personal) and a simple to-do/project
> task
> > manager.
> >
> > The one interesting aspect is that it supports collaborative file
> sharing
> > through a server with *disconnected operation/synchronization^
> capability.
> > It feels a lot like the Magi approach, I think, since you define who
> you're
> > working with and files propagate appropriately. It does require a
> central
> > server (and has the RSA license/certification brand placed prominently),
> so
> > it's not entirely equivalent.
> >
> > Any thoughts on this one? Mostly disconnected operation may be the next
> big
> > feature for portals, I think.
> >
> > Ken Meltsner
>
> --
> Gregory Alan Bolcer | gbolcer@endtech.com | work: 949.833.2800
> Chief Technology Officer | http://www.endtech.com | cell: 714.928.5476
> Endeavors Technology, Inc. | efax: 603.994.0516 | wap: 949.278.2805
This archive was generated by hypermail 2b29 : Mon Jun 19 2000 - 22:56:46 PDT