Hi Baker -- good points and questions.

On 4/16/07, Baker Hughes <[EMAIL PROTECTED]> wrote:
If you don't want to use their own 'Zen' object stuff, can you use
whatever you want? C#, VB, Java ?

Since Cache' has a development platform, like all MV systems have,
there is a p-machine side (like all MV systems except jBASE have) in
which their database code and all app code within Pick or MUMPS or
their OOP that incorporates these runs. As with (must/all) MV
solutions, this is not the same p-machine that runs Java bytecode
(although historically coming from the same place). But they have a
seemingly very well architected Java solution called Jalepeno, that I
think, maybe, perhaps (I haven't read much and what I read was a few
months back) permits one to access Cache' Objects specified as Java
objects. So, you work with stored cache' objects (which are records in
files to us U2 folks) like you work with any other objects, using
standard java libraries for collections and such.  You may also
execute SQL statements against them, but you don't have to.  This
feature was so impressive, the story goes (as told by Intersystems
folks, so IBM can jump in here to correct this if I have it wrong),
that IBM chose Cache' using Java and Jalepeno over U2 or any other IBM
databases for a call center project at IBM.

How does it like ODBC, ADO or other methods of getting to the Cache
data?

THE method for doing SQL to Cache' is ODBC/JDBC and they have made it
wicked fast from what I heard from customers in sessions at their
conference. I am very impressed with their technical savvy as a
company and their focus on performance and scalability, so I do not
doubt that it really is incredibly fast to use ODBC.  I haven't used
ADO myself and couldn't spell it if you asked me to. If someone
mentioned it (and they might have), it didn't stick in my brain.

We've all had our days hemmed into a proprietary environment.

Yup, now you are getting into the area where I wrestled myself to the
ground (and won, I think).

I hope I'm wrong for the sake of my comrades like Dawn, but I haven't
heard anything to make me think otherwise, but that your development
efforts will be dependent on that 1 company, and tied to their survival.

I have experience with multiple database environments and know there
is no such thing as database-agnostic applications through and
through. The "if" statements in an application that attempts to work
with more than one database are significant. Oddly, these might even
be fewer in the Pick world (crossing platforms such as UniData and
UniVerse, for example, even before they were jointly owned) than
between most SQL-DBMS's, even though there are industry standards for
SQL.

So, I had to decide whether to do what many companies do and tie
myself to a single database, making it a) hard to migrate to another
if we had to and b) hard to have a good negotiation position with the
database vendor should I need to. That is the reason that I am
planning to use MV BASIC code, rather than MUMPS code, for functions
within the software, first of all. Intersystems has almost a monopoly
on MUMPS, but they definitely have competition in Pick.

That doesn't get us all the way there, however, since there are the
Classes, particularly those that correspond to the UI. When moving
from one PIck solution to another today, the client-server or GUI is
the most likely thing to not move. I will be tied to Intersystems for
the UI, I realize.  It is one of the costs when doing my cost/benefits
analysis. I did not see that choosing UniData or UniVerse was going to
do better in this area and I have what I think are good reasons for
not using Oracle, SQL Server, or MySQL for the back end too (even if
getting them on paper is difficult). So, I am addressing that in the
relationship with the database vendor (ask me off-list if you are
interested, but I really have no brilliant answer to this concern and
it is one of my concerns).

The good news for me is that the model for software delivery has
changed. I will not be selling a product to multiple orgs who have to
install in on their systems, each with different requirements or
desires about what the DBMS would be. I can put whatever back-end on
this that I think is good and provide 'web services' (good data
exchange, at least) with related systems. The user can care about the
business solution in an SaaS solution, rather than the technical
components.  So, I don't have to sell Pick or Cache', but do have to
support the solution long-term and, yes, would be tied to a vendor at
least for the GUI (AJAX) side of things, but can do the business logic
in MV code, which has some portability, even if a migration would be
painful (as if there were migrations that were not, eh?)

Just some questions:
If it's so good then what vertical apps are porting to it?  (from MV or
RDMS spaces)

I had the feeling that those of us at this DEVCON are in the first
wave of post-general delivery prospective customers considering
migrating (after the initial "beta" folks).  It is likely that only
those of us who are not migrating (consultants like Tony and me and
companies writing new software, like my new venture) would want me to
give away their identity (they can speak up if they desire) since they
have competitors and are considering this move to be strategic
(perhaps also not wanting to alert IBM to the possibility if they are
considering Cache').

I will tell you that Cache' is huge in the health care vertical, which
is not my current area, so I was a bit concerned about that.  My
concerns were pretty much addressed by those in other verticals who
seem exceedingly happy with InterSystems and whose businesses are
thriving. Financials is another big vertical they are in, but they are
very clear that they are a tools, not apps, provider and they will
support application partners in any vertical with enthusiasm (and they
really do have such enthusiasm, both for their product and for my
business plan and interests).

Why are they going after the MV market so strongly ?

They bought out most of MUMPS and seem to have enough former PIck
folks there who were saying that it was a similar situation of needing
to take Pick apps into a broader environment with today's expectations
for 24/7 but with our (PICK folks') expectations of big bang for the
buck too.  In other words, we think like they do and there are, I
think, former pickies in their midst who said it was a good match. It
also sounds like they considered attempting to buy out the Pick market
like they did MUMPS a while back, but it didn't happen for whatever
reasons. So, they are providing what they think is an excellent
technology suite and it now includes MultiValue. They are clear with
their story (seemingly changing it from some time back) that there is
not Cache' for MV, but that Cache' now IS MV (as well as being MUMPS
and OOP).

After you've written your killer app, and the buyer wants a different
db, what are your options? (can you do a [somewhat] simple data/dict
conversion and take it to some *other* MV database?

As you have seen from above, I'm doing SaaS, so I do not have that
problem. They based their implementation of MV on UniVerse, I think,
so that would be the easiest port in the other direction (from Cache'
to UV), I would guess.

Have you seen any dollar figures on their R&D investment, compared to
other 2NF db providers?

No, but I have "felt" their environment, talked to their VP of
development and of marketing (among others) and I like their
philosophies and strategies. Feel free to ask any additional questions
about that off-list, but I honestly did buy into their corporate big
picture and their operational means to achieve their strategies. As
with any Pick "manufacturer" they are successful if their application
partners (e.g. VARS) are successful. They make that clear with their
creative approaches to pricing that aligns with your business model,
for example.

I hope that helps.  --dawn

-Baker

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dawn Wolthuis
Sent: Monday, April 16, 2007 2:36 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] U2 / Cache

I should perhaps put this on the U2C list, but I'll second some of
Tony's impressions of Cache'.  I am starting a new venture (adventure)
and have selected Cache', using their MV tools as well as their AJAX
tools, for the platform.

In my case, I have done a few talks here and there in the past couple of
years, with my primary focus in two areas: MV and AJAX. It was shocking
and delightful to see that there was a company spending a large amount
of its R&D dollars on two primary projects during this
time: MultiValue implementation and AJAX integration. So, I had to take
a look.

Their MUMPS technology (with objects added, just as they added object
features to MultiValue BASIC) is renamed Cache' Object Script. It is at
least as unimpressive at first glance to a non-MUMPS developer as Pick
might be to a non-Pick developer. But they set up the MV implementation
so that, in theory (I'm guessing there are exceptions), anywhere that
you can write MUMPS code, you can now write DataBASIC (Cache' MultiValue
BASIC). Very cool.

Cache' classes can be developed, looking similar to Java and other
object languages, that generate MultiValue dictionaries. These classes
then work with the rest of their AJAX implementation (named Zen). Any
Cache' class with methods in it can have those methods written in
MultiValue BASIC. As a sometimes Java developer, it is pretty
interesting to see this blend of OOP and MV.

Feel free to ask me any questions about the product or my decision on
this, if desired, especially as we get into more hands-on with the
product this summer (the devil is in the details and all).

Of course, there will always be a place in my heart for U2, but I had to
make the best decision for the new software we will be building and
InterSystems with their Cache' offering that now includes MultiValue
just "feels" more like the future, with their 24-7 approach, scalability
etc. There was really good energy at the conference and in discussions
with key Intersystems folks. I like the U2 group too, but they do not
have the same level of corporate-wide backing for their MV product that
Cache' has, so the innovations are not in the same place either.

Cheers!  --dawn

--
Dawn M. Wolthuis
Tincat Group, Inc.
tincat-group.com

Take and give some delight today
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/



--
Dawn M. Wolthuis
Tincat Group, Inc.  tincat-group.com

Take and give some delight today
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Reply via email to