Trialling MM v8.5 after years on v7.5

[J.Lance Wilkinson, 814-865-1818]

After nearly 3 years on MM v7.5, I've been charged with upgrading
to MM v8.5 within about a 6 week period. Because of some warnings
about a major difference in the client's appearance, it was decided
that we would bring up a sandbox with an emulation of our current configuration
(4 servers, AND HUB, with the HUB and 2 of the servers on the same Win2K
server, the other two servers on discrete Win2K or Win2003 boxes elsewhere)
and deploy some test client boxes to play with it and get a feel for where
our users' helpdesk queries would be coming from.

We've populated with content back thru January 1, 2005 exported from
the MMDATA.BAK files created Tuesday morning on our various servers.

My first opinions pretty well justify our efforts of bringing up the sandbox.
I see a drastically different "look" of the new client. In some ways, nice.
In other ways, YUCK. Double YUCK with a beating by an ugly stick in fact.

What did the 7.5 Mac interface look like? I note that there's virtually no
difference between the Mac and Windows looks now.

Anybody know how, if at all, it's possible to get the "classic" look back? Or
at least to view To-Do, Weekly (8.5's name for 7.5's Daily) and Monthly to
display simultaneously in different corners of the master window? I'm USED to
working with a Windows screen laid out this way; I certainly don't want to
have to click links back & forth instead of viewing these simultaneously:

<pre>
+------------------------+-----------------+
|To-Do List |Daily View |
| | |
| | |
| | |
| | |
+------------------------+ |
|Monthly View | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
+------------------------+-----------------+
</pre>

+----"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+
| J.Lance Wilkinson ("Lance") InterNet: ***@psu.edu
| Systems Design Specialist - Lead AT&T: [phone]
| Digital Library Technologies FAX: [phone]
| 3 Paterno Library "I'd rather be dancing..."
| Penn State University A host is a host from coast to coast,
| University Park, PA 16802 And no one will talk to a host that's close
| <***@psulias.psu.edu> Unless the host that isn't close
| EMail Professional since 1978 Is busy, hung or dead.
+---------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+
[apologies to DeForest Kelley, 1920-1999]
<A Href="http://perdita.lcs.psu.edu">home page</a>
<a Href="http://perdita.lcs.psu.edu/junkdec.htm">junk mail declaration</a>
-- /"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Ian Eiloart]

--On 11 May 2005 15:36:49 -0400 "J.Lance Wilkinson, 814-865-1818"
<***@PSULIAS.PSU.EDU> wrote:


>
> What did the 7.5 Mac interface look like? I note that there's virtually
> no difference between the Mac and Windows looks now.

It was also fairly similar with 7.5. I much prefer the new interface. It's
makes all workflows easier, and exposes more of the functionality to people
who aren't experimenters. There are also much better ways of viewing
proxies.

> Anybody know how, if at all, it's possible to get the "classic" look
> back?

Well, they have a "classic" view - which changes the vertical scale in the
daily and weekly views. You need v8.5.1 to get that. Click the "edit view
options" button to see it. You want more than that though:

You'll also want to get rid of the "task bar" on the left of the windows.
You can't - but you can drag the divider to reduce it to small icons.

You also want two calendar windows open. Select "New Main Window" from the
file menu. Repeat until you have enough calendar windows. Then select "to
do list" from the Window menu. Now arrange them to taste.


> Or at least to view To-Do, Weekly (8.5's name for 7.5's Daily) and
> Monthly to display simultaneously in different corners of the master
> window? I'm USED to working with a Windows screen laid out this way; I
> certainly don't want to have to click links back & forth instead of
> viewing these simultaneously:
>
> <pre>
> +------------------------+-----------------+
>| To-Do List |Daily View |
>| | |
>| | |
>| | |
>| | |
> +------------------------+ |
>| Monthly View | |
>| | |
>| | |
>| | |
>| | |
>| | |
>| | |
>| | |
> +------------------------+-----------------+
> </pre>
>
> +----"Never Underestimate the bandwidth of a station wagon full of mag
> tapes"--+
>| J.Lance Wilkinson ("Lance") InterNet: ***@psu.edu
>| Systems Design Specialist - Lead AT&T: [phone]
>| Digital Library Technologies FAX: [phone]
>| 3 Paterno Library "I'd rather be dancing..."
>| Penn State University A host is a host from coast to coast,
>| University Park, PA 16802 And no one will talk to a host that's close
>| <***@psulias.psu.edu> Unless the host that isn't close
>| EMail Professional since 1978 Is busy, hung or dead.
> +---------"He's dead, Jim. I'll get his tricorder. You take his
> wallet."-------+ [apologies to DeForest Kelley, 1920-1999]
> <A Href="http://perdita.lcs.psu.edu">home page</a>
> <a Href="http://perdita.lcs.psu.edu/junkdec.htm">junk mail declaration</a>
> -- /"\
> \ / ASCII RIBBON CAMPAIGN
> X AGAINST HTML MAIL
> / \
>
>
> * MMXP-TALK Web Page:
> http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML



--
Ian Eiloart
Servers Team
Sussex University ITS


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[J.Lance Wilkinson, 814-865-1818]

On Thu, 12 May 2005 10:27:14, Meeting Maker Discussion List
<MMXP-***@listserv.cc.EMORY.EDU> wrote:

>--On 11 May 2005 15:36:49 -0400 "J.Lance Wilkinson, 814-865-1818"
><***@PSULIAS.PSU.EDU> wrote:
>
>> Anybody know how, if at all, it's possible to get the "classic" look
>> back?
>
>Well, they have a "classic" view - which changes the vertical scale in the
>daily and weekly views. You need v8.5.1 to get that. Click the "edit view
>options" button to see it. You want more than that though:
>
>You'll also want to get rid of the "task bar" on the left of the windows.
>You can't - but you can drag the divider to reduce it to small icons.

Even IE has a little "X" you can click to get rid of that task
bar. If they're going for an "Outlook" look and that monstrosity
doesn't have said "X" to click, they could augment it a little
and give us the option, couldn't they? What a waste of real estate.

>You also want two calendar windows open. Select "New Main Window" from the
>file menu. Repeat until you have enough calendar windows. Then select "to
>do list" from the Window menu. Now arrange them to taste.

Yep. I just didn't realize one needed the extra step to create a "New
Main Window." It was just choosing another view before; otherwise
it's the same technique as in 7.5 and earlier releases.

On my test client box, a Win2K system, the ToDo list font that's been
selected is a strange one -- almost looks like the WingDings font.
Totally unintelligible. Same font is used in the server lists
displayed when selecting a server during signin and in the MMAdmin
open server/hub dialog. I did not observe this on the Win2K server
where I've hosted the trail servers and hub, and nobody else has
commented on it although at least one other person has installed the
client and started to play in the sandbox, so I suspect it's a
workstation-specific issue with my trial client box.

+----"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+
| J.Lance Wilkinson ("Lance") InterNet: ***@psu.edu
| Systems Design Specialist - Lead AT&T: [phone]
| Digital Library Technologies FAX: [phone]
| 3 Paterno Library "I'd rather be dancing..."
| Penn State University A host is a host from coast to coast,
| University Park, PA 16802 And no one will talk to a host that's close
| <***@psulias.psu.edu> Unless the host that isn't close
| EMail Professional since 1978 Is busy, hung or dead.
+---------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+
[apologies to DeForest Kelley, 1920-1999]
<A Href="http://perdita.lcs.psu.edu">home page</a>
<a Href="http://perdita.lcs.psu.edu/junkdec.htm">junk mail declaration</a>
-- /"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Margaret A. Menzies]

>> On my test client box, a Win2K system, the ToDo list font that's been
>> selected is a strange one -- almost looks like the WingDings font.
>> Totally unintelligible.

This is what we have labeled the "dingbats problem" and it is workstation specific.

The good news is that we have fixed this in our 8.5.1 client release and will have the same fix on our GUI Admin in the next server release out later this summer.

Margaret

Margaret A. Menzies
VP Development
Meeting Maker, Inc
E: ***@meetingmaker.com

Preview Meeting Maker's Mobile Calendar & Email product at the Solutions Conference May 23-27, 2005!
Learn more at: http://www.meetingmaker.com/solutions2005.cfm




* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Jack Newton]

" Even IE has a little "X" you can click to get rid of that task
bar. If they're going for an "Outlook" look and that monstrosity
doesn't have said "X" to click, they could augment it a little
and give us the option, couldn't they? What a waste of real estate."

Like the quarter inch of lost real estate is what I consider a BIG problem. Yes it would be "nice" but let's worry about bigger issues....

Can't say we need classic view but it has made a few users happy (the less technical ones I might add).

Jack


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[J.Lance Wilkinson, 814-865-1818]

On Thu, 12 May 2005 11:42:35, Meeting Maker Discussion List
<MMXP-***@listserv.cc.EMORY.EDU> wrote:

>>> On my test client box, a Win2K system, the ToDo list font that's been
>>> selected is a strange one -- almost looks like the WingDings font.
> >> Totally unintelligible.
>
>This is what we have labeled the "dingbats problem" and it is workstation specific.
>
>The good news is that we have fixed this in our 8.5.1 client release and will
>have the same fix on our GUI Admin in the next server release out later this
>summer.

And what, pray tell, is the schedule for this new server release?
Would we be better off, when we have 4 servers, a hub, and over 500
users shared between 4 administrative units and these 4 servers, to
wait for the release and burn-in of this new server release? Or
will this new server release be compatible with clients/servers/hubs
of the 8.5 version such that we'd not need yet another rip'n'replace
to let users experiencing this "dingbats problem" or wishing to take
advantage of features of the new server without forcing others to
follow in lockstep?

>
>Margaret
>
>Margaret A. Menzies
>VP Development
>Meeting Maker, Inc
>E: ***@meetingmaker.com

+----"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+
| J.Lance Wilkinson ("Lance") InterNet: ***@psu.edu
| Systems Design Specialist - Lead AT&T: [phone]
| Digital Library Technologies FAX: [phone]
| 3 Paterno Library "I'd rather be dancing..."
| Penn State University A host is a host from coast to coast,
| University Park, PA 16802 And no one will talk to a host that's close
| <***@psulias.psu.edu> Unless the host that isn't close
| EMail Professional since 1978 Is busy, hung or dead.
+---------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+
[apologies to DeForest Kelley, 1920-1999]
<A Href="http://perdita.lcs.psu.edu">home page</a>
<a Href="http://perdita.lcs.psu.edu/junkdec.htm">junk mail declaration</a>
-- /"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[J.Lance Wilkinson, 814-865-1818]

On Thu, 12 May 2005 15:49:51, Meeting Maker Discussion List
<MMXP-***@listserv.cc.EMORY.EDU> wrote:

>" Even IE has a little "X" you can click to get rid of that task
> bar. If they're going for an "Outlook" look and that monstrosity
> doesn't have said "X" to click, they could augment it a little
> and give us the option, couldn't they? What a waste of real estate."
>
>Like the quarter inch of lost real estate is what I consider a BIG problem.
>Yes it would be "nice" but let's worry about bigger issues....
>
>Can't say we need classic view but it has made a few users happy (the less
>technical ones I might add).

That quarter inch of real estate can result in literally hundreds of
man hours in HELPDESK calls trying to train users on the different
look and feel of something that was basically "If it ain't broke,
don't fix it." Problem is, we've been paying for maintenance with
nothing the purse holder sees to gain from it, and there ARE things
which are seriously broke in 7.5 that are only fixed in 8.x (e.g.,
HELP doesn't work on WinXP).

The biggest issue I see, however, is unchanged since MM v2.3 days.
A user with no reason to upgrade MUST because there's no backward
compatibility between server and client.

+----"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+
| J.Lance Wilkinson ("Lance") InterNet: ***@psu.edu
| Systems Design Specialist - Lead AT&T: [phone]
| Digital Library Technologies FAX: [phone]
| 3 Paterno Library "I'd rather be dancing..."
| Penn State University A host is a host from coast to coast,
| University Park, PA 16802 And no one will talk to a host that's close
| <***@psulias.psu.edu> Unless the host that isn't close
| EMail Professional since 1978 Is busy, hung or dead.
+---------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+
[apologies to DeForest Kelley, 1920-1999]
<A Href="http://perdita.lcs.psu.edu">home page</a>
<a Href="http://perdita.lcs.psu.edu/junkdec.htm">junk mail declaration</a>
-- /"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Jack Newton]

It's fixed in the 8.5.1 client that's out now, why are you harping on them for the next release date? it's not like we didn't know they were going to come out with a new release this year....?

Jack


> On Thu, 12 May 2005 11:42:35, Meeting Maker Discussion List
> <MMXP-***@listserv.cc.EMORY.EDU> wrote:
>
> >>> On my test client box, a Win2K system, the ToDo list font that's been
> >>> selected is a strange one -- almost looks like the WingDings font.
> > >> Totally unintelligible.
> >
> >This is what we have labeled the "dingbats problem" and it is workstation
> specific.
> >
> >The good news is that we have fixed this in our 8.5.1 client release and will
> >have the same fix on our GUI Admin in the next server release out later this
> >summer.
>
> And what, pray tell, is the schedule for this new server release?
> Would we be better off, when we have 4 servers, a hub, and over 500
> users shared between 4 administrative units and these 4 servers, to
> wait for the release and burn-in of this new server release? Or
> will this new server release be compatible with clients/servers/hubs
> of the 8.5 version such that we'd not need yet another rip'n'replace
> to let users experiencing this "dingbats problem" or wishing to take
> advantage of features of the new server without forcing others to
> follow in lockstep?
>
> >
> >Margaret
> >
> >Margaret A. Menzies
> >VP Development
> >Meeting Maker, Inc
> >E: ***@meetingmaker.com
>
> +----"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+
> | J.Lance Wilkinson ("Lance") InterNet: ***@psu.edu
> | Systems Design Specialist - Lead AT&T: [phone]
> | Digital Library Technologies FAX: [phone]
> | 3 Paterno Library "I'd rather be dancing..."
> | Penn State University A host is a host from coast to coast,
> | University Park, PA 16802 And no one will talk to a host that's close
> | <***@psulias.psu.edu> Unless the host that isn't close
> | EMail Professional since 1978 Is busy, hung or dead.
> +---------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+
> [apologies to DeForest Kelley, 1920-1999]
> <A Href="http://perdita.lcs.psu.edu">home page</a>
> <a Href="http://perdita.lcs.psu.edu/junkdec.htm">junk mail declaration</a>
> -- /"\
> \ / ASCII RIBBON CAMPAIGN
> X AGAINST HTML MAIL
> / \
>
>
> * MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Jack Newton]

" That quarter inch of real estate can result in literally hundreds of
man hours in HELPDESK calls trying to train users on the different
look and feel of something that was basically "If it ain't broke,
don't fix it." Problem is, we've been paying for maintenance with
nothing the purse holder sees to gain from it, and there ARE things
which are seriously broke in 7.5 that are only fixed in 8.x (e.g.,
HELP doesn't work on WinXP).

The biggest issue I see, however, is unchanged since MM v2.3 days.
A user with no reason to upgrade MUST because there's no backward
compatibility between server and client. "

It's not the quarter inch of real estate your talking about then, your talking about the release of a new client. Meeting Maker hasn't changed the look in their client for almost 10 years, let's face it they were due for a face lift. At least they offered users a classic look.

Since your issues are fixed in the new release it seems that your maintenance went towards something after all.

But it looks to me like you're just angry that the interface is changing and you have to retrain users. Yes, training users can be an issue. Obviously you have to weigh upgrading to fix your issues towards retraining your users. Same as if you installed a new OS for them as well. Classic IT problem.

Jack


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Jack Newton]

"The biggest issue I see, however, is unchanged since MM v2.3 days.
A user with no reason to upgrade MUST because there's no backward
compatibility between server and client. "

Do you really expect a version 5 client to work on a 8.5 server with a different database structure and communications model?

There is compatibility between certain versions - 6.0.4 - 6.0.8, 7.1-7.5.3. It's when a major release happens that you lose the compatibility between client and server. This is pretty much true with most database programs as well.

Jack


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Ian Eiloart]

--On 12 May 2005 16:32:01 +0000 Jack Newton <***@COMCAST.NET> wrote:

> "The biggest issue I see, however, is unchanged since MM v2.3 days.
> A user with no reason to upgrade MUST because there's no backward
> compatibility between server and client. "
>
> Do you really expect a version 5 client to work on a 8.5 server with a
> different database structure and communications model?
>
> There is compatibility between certain versions - 6.0.4 - 6.0.8,
> 7.1-7.5.3. It's when a major release happens that you lose the
> compatibility between client and server. This is pretty much true with
> most database programs as well.
>

I certainly do. Our mail servers (SMTP and IMAP) work with mail clients
that are essentially unchanged in 20 years. All you need is a stable
communications protocol. If the product were designed right, this would be
easy.

--
Ian Eiloart
Servers Team
Sussex University ITS


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Steve Burling]

--On May 12, 2005 4:32:01 PM +0000 Jack Newton <***@COMCAST.NET>
wrote:

> Do you really expect a version 5 client to work on a 8.5 server with a
> different database structure and communications model?

No, but it would have been nice of a minimum amount of compatibility
between a new server release and the previous client release could be
maintained, to ease the upgrade burden by allowing it to be spread out over
time.

> There is compatibility between certain versions - 6.0.4 - 6.0.8,
> 7.1-7.5.3. It's when a major release happens that you lose the
> compatibility between client and server. This is pretty much true with
> most database programs as well.

And it's been a huge pain in the ass for people who run large MM
environments with distributed authority, ever since MM introduced the
concept of hubs. I used to run a couple of large servers and the hub, to
which were attached another half-dozen servers that were not under my
administrative control (gotta love universities). Scheduling upgrades was
an absolute nightmare. And given how badly the automatic upgrade process
worked we had to have many folks going around to machines to do client
upgrades after the server upgrade (which was usually a nightmare in itself).

For the last few years, I've been running a nice small, stand-alone server
that runs on Solaris. I pretty much ignore it. I get much more sleep. :-)

--
Steve Burling <mailto:***@umich.edu>
University of Michigan, ICPSR Voice: +1 734 615.3779
330 Packard Street FAX: [phone]
Ann Arbor, MI 48104-2910


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Jack Newton]

Your talking about email that any program can retreive based on a universal standard (SMTP/IMAP), not a program that is connecting to a central database and manipulating data. Let's talk apples to apples, not apples and oranges.

Jack


> --On 12 May 2005 16:32:01 +0000 Jack Newton <***@COMCAST.NET> wrote:
>
> > "The biggest issue I see, however, is unchanged since MM v2.3 days.
> > A user with no reason to upgrade MUST because there's no backward
> > compatibility between server and client. "
> >
> > Do you really expect a version 5 client to work on a 8.5 server with a
> > different database structure and communications model?
> >
> > There is compatibility between certain versions - 6.0.4 - 6.0.8,
> > 7.1-7.5.3. It's when a major release happens that you lose the
> > compatibility between client and server. This is pretty much true with
> > most database programs as well.
> >
>
> I certainly do. Our mail servers (SMTP and IMAP) work with mail clients
> that are essentially unchanged in 20 years. All you need is a stable
> communications protocol. If the product were designed right, this would be
> easy.
>
> --
> Ian Eiloart
> Servers Team
> Sussex University ITS
>
>
> * MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Ian Eiloart]

--On 12 May 2005 16:44:51 +0000 Jack Newton <***@COMCAST.NET> wrote:

> Your talking about email that any program can retreive based on a
> universal standard (SMTP/IMAP), not a program that is connecting to a
> central database and manipulating data. Let's talk apples to apples, not
> apples and oranges.
>
> Jack

There's no difference in principle. The IMAP server is essentially a
database management system. The mail client connects to it, can create,
retrieve and modify records (emails). Several clients can share tables
(mailboxes). The underlying storage is abstracted by the server - it could
be plain text files or a sophisticated database like exchange.

I've got mail clients that support features unsupported by my server, and
vice versa. The first thing that the client does when it connects to the
server is ask what features it supports.

There's nothing in Meeting Maker 8 that can't be displayed in the v7
client. It isn't necessary for the v7 client to create or modify the new
record types - just to display them. If the server needs to help out, by
splitting repeating banners into individual events to send to the client,
then so be it.

>
>> --On 12 May 2005 16:32:01 +0000 Jack Newton <***@COMCAST.NET>
>> wrote:
>>
>> > "The biggest issue I see, however, is unchanged since MM v2.3 days.
>> > A user with no reason to upgrade MUST because there's no
>> > backward compatibility between server and client. "
>> >
>> > Do you really expect a version 5 client to work on a 8.5 server with a
>> > different database structure and communications model?
>> >
>> > There is compatibility between certain versions - 6.0.4 - 6.0.8,
>> > 7.1-7.5.3. It's when a major release happens that you lose the
>> > compatibility between client and server. This is pretty much true with
>> > most database programs as well.
>> >
>>
>> I certainly do. Our mail servers (SMTP and IMAP) work with mail clients
>> that are essentially unchanged in 20 years. All you need is a stable
>> communications protocol. If the product were designed right, this would
>> be easy.
>>
>> --
>> Ian Eiloart
>> Servers Team
>> Sussex University ITS
>>
>>
>> * MMXP-TALK Web Page:
>> http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML
>
>
> * MMXP-TALK Web Page:
> http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML



--
Ian Eiloart
Servers Team
Sussex University ITS


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Jack Newton]

Unfortunately you're oversimplifying the issues. When you add new features to a product design, the database design in most cases has to change.

In the case of Meeting Maker, when they went from server side time zones to client side time zones, they would have had to recode all of the dated items with a different format.
That type of issue doesn't exist in email land.

So I guess in this case we can agree to disagree as it seems obvious you're pretty convinced that databases can always remain compatible with a product 20 years later (glad I'm not coding it).

Jack


> --On 12 May 2005 16:44:51 +0000 Jack Newton <***@COMCAST.NET> wrote:
>
> > Your talking about email that any program can retreive based on a
> > universal standard (SMTP/IMAP), not a program that is connecting to a
> > central database and manipulating data. Let's talk apples to apples, not
> > apples and oranges.
> >
> > Jack
>
> There's no difference in principle. The IMAP server is essentially a
> database management system. The mail client connects to it, can create,
> retrieve and modify records (emails). Several clients can share tables
> (mailboxes). The underlying storage is abstracted by the server - it could
> be plain text files or a sophisticated database like exchange.
>
> I've got mail clients that support features unsupported by my server, and
> vice versa. The first thing that the client does when it connects to the
> server is ask what features it supports.
>
> There's nothing in Meeting Maker 8 that can't be displayed in the v7
> client. It isn't necessary for the v7 client to create or modify the new
> record types - just to display them. If the server needs to help out, by
> splitting repeating banners into individual events to send to the client,
> then so be it.
>
> >
> >> --On 12 May 2005 16:32:01 +0000 Jack Newton <***@COMCAST.NET>
> >> wrote:
> >>
> >> > "The biggest issue I see, however, is unchanged since MM v2.3 days.
> >> > A user with no reason to upgrade MUST because there's no
> >> > backward compatibility between server and client. "
> >> >
> >> > Do you really expect a version 5 client to work on a 8.5 server with a
> >> > different database structure and communications model?
> >> >
> >> > There is compatibility between certain versions - 6.0.4 - 6.0.8,
> >> > 7.1-7.5.3. It's when a major release happens that you lose the
> >> > compatibility between client and server. This is pretty much true with
> >> > most database programs as well.
> >> >
> >>
> >> I certainly do. Our mail servers (SMTP and IMAP) work with mail clients
> >> that are essentially unchanged in 20 years. All you need is a stable
> >> communications protocol. If the product were designed right, this would
> >> be easy.
> >>
> >> --
> >> Ian Eiloart
> >> Servers Team
> >> Sussex University ITS
> >>
> >>
> >> * MMXP-TALK Web Page:
> >> http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML
> >
> >
> > * MMXP-TALK Web Page:
> > http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML
>
>
>
> --
> Ian Eiloart
> Servers Team
> Sussex University ITS
>
>
> * MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Ian Eiloart]

--On 13 May 2005 12:24:55 +0000 Jack Newton <***@COMCAST.NET> wrote:

> Unfortunately you're oversimplifying the issues. When you add new
> features to a product design, the database design in most cases has to
> change.

Of course. But that doesn't matter. What matters is the specification of
the communications protocol.

> In the case of Meeting Maker, when they went from server side time zones
> to client side time zones, they would have had to recode all of the dated
> items with a different format. That type of issue doesn't exist in email
> land.
>
> So I guess in this case we can agree to disagree as it seems obvious
> you're pretty convinced that databases can always remain compatible with
> a product 20 years later (glad I'm not coding it).

No, its the communications layer that counts, not the underlying
representation. The communications layer can hide the new features, or
re-represent them to older clients.

20 years later is a straw man, too. All that's required is compatibility
with the previous client version. I don't mind getting all my clients up to
version 7 before deploying the version 8 server, then letting people have
the version 8 client at their leisure. What I do mind is having to update
hundreds of clients on the same day that I do the server update. It's a
nightmare to organise.


> Jack
>
>
>> --On 12 May 2005 16:44:51 +0000 Jack Newton <***@COMCAST.NET>
>> wrote:
>>
>> > Your talking about email that any program can retreive based on a
>> > universal standard (SMTP/IMAP), not a program that is connecting to a
>> > central database and manipulating data. Let's talk apples to apples,
>> > not apples and oranges.
>> >
>> > Jack
>>
>> There's no difference in principle. The IMAP server is essentially a
>> database management system. The mail client connects to it, can create,
>> retrieve and modify records (emails). Several clients can share tables
>> (mailboxes). The underlying storage is abstracted by the server - it
>> could be plain text files or a sophisticated database like exchange.
>>
>> I've got mail clients that support features unsupported by my server,
>> and vice versa. The first thing that the client does when it connects
>> to the server is ask what features it supports.
>>
>> There's nothing in Meeting Maker 8 that can't be displayed in the v7
>> client. It isn't necessary for the v7 client to create or modify the new
>> record types - just to display them. If the server needs to help out, by
>> splitting repeating banners into individual events to send to the
>> client, then so be it.
>>
>> >
>> >> --On 12 May 2005 16:32:01 +0000 Jack Newton <***@COMCAST.NET>
>> >> wrote:
>> >>
>> >> > "The biggest issue I see, however, is unchanged since MM v2.3 days.
>> >> > A user with no reason to upgrade MUST because there's no
>> >> > backward compatibility between server and client. "
>> >> >
>> >> > Do you really expect a version 5 client to work on a 8.5 server
>> >> > with a different database structure and communications model?
>> >> >
>> >> > There is compatibility between certain versions - 6.0.4 - 6.0.8,
>> >> > 7.1-7.5.3. It's when a major release happens that you lose the
>> >> > compatibility between client and server. This is pretty much true
>> >> > with most database programs as well.
>> >> >
>> >>
>> >> I certainly do. Our mail servers (SMTP and IMAP) work with mail
>> >> clients that are essentially unchanged in 20 years. All you need is a
>> >> stable communications protocol. If the product were designed right,
>> >> this would be easy.
>> >>
>> >> --
>> >> Ian Eiloart
>> >> Servers Team
>> >> Sussex University ITS
>> >>
>> >>
>> >> * MMXP-TALK Web Page:
>> >> http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML
>> >
>> >
>> > * MMXP-TALK Web Page:
>> > http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML
>>
>>
>>
>> --
>> Ian Eiloart
>> Servers Team
>> Sussex University ITS
>>
>>
>> * MMXP-TALK Web Page:
>> http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML
>
>
> * MMXP-TALK Web Page:
> http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML



--
Ian Eiloart
Servers Team
Sussex University ITS


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Steve Burling]

--On May 13, 2005 12:24:55 PM +0000 Jack Newton <***@COMCAST.NET>
wrote:

> So I guess in this case we can agree to disagree as it seems obvious
> you're pretty convinced that databases can always remain compatible with
> a product 20 years later (glad I'm not coding it).

To which I reply:

As far as I've seen, no one has asked for things to remain compatible for
20 years -- just for *one* *single* *level* of backwards compatibility, to
ease the burden of having to simultaneously upgrade hundreds or thousands
of clients. That, imho, is a very reasonable request, and one I've been
asking for, politely, from version 2 onward.

Heck, Oracle manages to do it...

No one's asking for an old client to have full functionality with a new
server's new features. That *would* be unreasonable. But versioning
protocols, and providing limited functionality for clients using older
protocols is something that's well-understood in the software engineering
field, and has been for many years (I've got the gray hair to prove it!)

--
Steve Burling <mailto:***@umich.edu>
University of Michigan, ICPSR Voice: +1 734 615.3779
330 Packard Street FAX: [phone]
Ann Arbor, MI 48104-2910


* MMXP-TALK Web Page: http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML