The new eXo in the market

["Matthias Klein" <matthias@xxxxxxxxxx>]

Hi there,
When I looked at the new eXo a little while ago I thought "wow" at first.
But then some questions arose that I'd like to discuss if you don't mind:

The first one is: Don't I lose all platform independence (one of the motives
for things like jsr-168) if a 3PD produces a portlet for eXo which seems to
require a whole lot of Ajax and exo specific stuff?

The second one: what can I do "out of the box" with eXo? I mean: really DO
(as in "work")? Some of the built in portlets seem like technology focused
proofs of concept or "basic" techi-portlets to me when I compare them to
what I am used to from other portals.

If eXo SARL wants to be a platform provider, the valid answer to my 2nd
question would be "not too much" - but that's okay for a platform. But a
platform lives only through its content (e.g. Portlets). Is there or will
there be a list of available portlets or eXo based applications (both free
and commercial ones) of eXo and 3PD?

My third question was: When I think of our customers (Mainly the management
of automotive and logistics companies for which we provide business
intelligence solutions) I notice that some of them really want to use
portals. But they don't care about technology - so they don't see the beauty
portals like eXo may posess internally. All they want to do is get their
work done in an integrated way. And I am wondering: why would they want eXo
instead of Sharepoint or an IBM portal? And I must say: I don't know. Can
you tell me?

Let me give you a standard scenario:
Some management department wishes to concentrate the BI activities and
related document management and communicational needs into a portal. They
want 2-3 transactional applications (managing some data stored in different
databases and data warehouses), document management, user management with
profiles and means to communicate, they want 20 parametrized reports (it
depends on their role which report they are allowed to see and what
parameters can be used) with export to Excel and PDF and a print function
and they want 12 100-page Powerpoint reports automatically created in
different intervals with different parameter sets and have them sent to over
1000 people by email and as well stored for later reference and made
accessible based on the user role through the document management. They want
all of this to happen in a portal so they can later plug new applications
into it that accesses the same data and fully integrates with existing
stuff. And all of this pronto.

Okay, if I choose Sharepoint for this, I get the portal, user management,
role based user mgmt (which integrates with the existing corporate
directory), several communicational means, the document management (with
versioning and such), the mailing list and contact list management, outlook
synchronization of contacts and calendars and this type of stuff out of the
box. Takes me a few days to install and configure but then we are good to
go.
Now the developers open their Visual Studio and create a new WebPart -
assisted by a wizard which does lots of the heavy lifting for them. A few
mouse clicks later they have created several datasets connecting to the
different data sources they need. Then they write the transactional
application (usually simply by creating new dialogues, pulling widgets into
the pane of which many are databound - so there is no need to write any
additional source code to make dialogues that allow data entry and data
retrieval. Shortly such an application is done (Example: our last
application with 50 data management dialogues, validators, role based
access... Took 2 developers 2 months to write - including the specification,
test, deployment and documentation). Okay. Now we have the 2-3 transactional
applications.
Now let's tackle the 20 parametrized reports. For that I open my Visual
Studio, create a new reporting services report, define the dataset and get
the wizard to create the required mix of tables, graphics or pivot tables
(with or without grouping, drill-down or parameter based handling of
widgets). To have such a report up and running usually takes 1-3 days -
depending on its complexity. Export into several formats such as Excel and
PDF comes out of the box. Print function as well. And depending on which way
I write this report, the parameter page is automatically created for me (I
usually write my own because then I can control it better - but that doesn't
take long)
Now about the last part: the automatically created multi-page PPT reports.
Using a PPT library in Visual Studio that's easy. Just create the dataset
for each slide, use templates for standard diagrams or write own diagrams
(consultants can be VERY creative when it comes to inventing new diagram
types!) by configuring standard slide items or by writing C# code using the
API of the PPT library. In average, per slide you need 1-3 days as well.
Simple ones containing lists or tables or standard diagrams can be finished
within very few hours or even less.
The document management handles the storing of created slides, the report
factory handles the schedule-driven creation of these reports and the list
management sends the reports to all subscribers.
After only few months this entire application with all reports and
transactional application (in other words: large portions of the business
processes of this management department) is up and running.
We have done all these things mentioned with Sharepoint so far and we
appreciated the many out of the box functions and the huge amount of IDE
integration (Visual Studio has really powerful wizards and templates for
about everything) so developing new functions is really easy and quick
(which is the most important thing).

Now I am wondering if and how I could have done the same (or more) with eXo
in shorter time? 

Thanks

Matt