Well, yes, that will be the most common issue. But OOXML is supposed to open up documents for easy, cheap creation and manipulation by third parties. It's Microsoft's response to the ODF claim that now, you don't need the application which generated the data file.
Why is this an advantage? Well, imagine that you have a webserver serving financial quotes, and want to generate those quotes on the fly using the very latest data. Now you can output those quotes as documents quickly and easily, because you have the spec, right?
(Pedantically, yes you might choose to use PDF because it's "non-modifiable". I have a copy of WordPerfect X3 that allows roundtrip editing of PDFs. I have PDF cracking software that removes passwords/locks. And I have a copy of Acrobat. I'll modify your PDF if I want to. If you want to ensure your quote remains secure, then either don't give them the file or keep a copy of it for comparison later... Now back to the example.)
With ODF, outputting the file is easy. Same with OOXML. They're about equal for new documents.
What if your app needed instead to read old documents for some reason? Perhaps it's looking for links into your CRM system, using hints like the text before "yours sincerely" or for text which is right-formatted at the top of a page?
So to make this easier, you bulk convert your old data to OOXML. And then set your agent loose on the data.
Now what does useWord97LineBreakRules mean to you? Formatting is important in this context. It's how you're trying to recognise data. What the heck is a Word 97 Line Break Rule? Apparently, it refers to Far Eastern language blocks. Does it explain the weird formatting in all your RTL formatted paragraphs? Is this why the program works on documents from your Western offices but not ones from the Eastern offices?
A specification's job is to tell you not only that something exists, but also what it's for and what is does. Too often, Microsoft wave the "it's old, don't use it" wand in their OOXML spec, and whilst that's fine for new documents it's an appalling disservice to the documents you already have.
Of course, this is to Microsoft's advantage anyway. Having read about the spec, I plan to try and read it. But I think that I'll stick to OLE automation when it comes to manipulating Office documents, because the OLE/COM interfaces are better documented and better supported. And they have the advantage of letting Word figure out what the heck useWord97LineBreakRules means, rather than them having to do it.
This is probably what Microsoft want. Every application which reads and writes OOXML files natively and isn't part of Office is, to them, a potential lost Office sale. Why go out of their way to support that? OOXML sets the bar for using their XML suitably high, encouraging developers to use the existing OLE/COM interface rather than use the XML.
(And in my job I maintain a small app which uses OLE/COM to scrape data from an Excel spreadsheet that the user provides, so I'm fairly sure that OLE/COM would be easier than using the XML. Why did I use OLE/COM? Because the users tend to prepare the data in Excel anyway, so it cuts down on the steps required. I'd rather pull it from CSV or XML if I had the choice, but Excel is more convenient for the users on the whole, and prevents me from having to explain what File -> Save As does over and over again. And most importantly, because someone else wrote the core of the app, and I inherited it like that later. I've just been tweaking it as necessary. *grins*)
To go back to my example - who would want to scan their old documents and put them into a CRM system as possible related items? Well, I bet most businesses would be open to the idea. Until they see the cost. I'd also bet that it would be cheaper to accomplish with ODF documents than it would OOXML documents, because of the kinds of issues I've mentioned. In that regard, OOXML will actually hold back the IT industry - it will prevent cool things from being
The usual question is "why can't I just use our shared mapped drives?" - so here's what you DON'T get from shared mapped drives that you do get from a Document Management System (DMS):
* Metadata... Basic metadata on the document which can help searching, and can sometimes be sorted upon etc. The metadata often varies with the "document type" - so tender documents/procurement documents have an Account field, where meeting minutes instead have an Attendees field. Yes, this takes more time to fill in when saving a document into a DMS. This is why users hate the DMS. Business loves it, of course, because it makes things easy to find years later.
* Structure... You create the overall structure, and nobody can change it. We've all seen file shares that have had no control - they become an impenetrable mess of folders, because everyone has their own slightly different filing system they're adhering to. DMS software allows an organisation to enforce just one filing system. Users hate that, too.;-)
* Conflict Prevention... Most DMS software has the concept of "checking out" a document, just like you would check out a book at the library. Whilst you have that document checked out, everyone can see you're working on it - and nobody else can check it out. This prevents two idiots^Wusers from applying changes to the same document. Checking a document out also allows for an audit trail to be built.
* Versioning... Beyond the versioning that you get in Word - this is literally keeping a copy of every version that was checked in. You can usually also add a metadata comment for each vesrion when you check it in, to say what you changed. Often, you can even do this for each draft. Oh, by the way, being able to mark documents as either drafts or versions is also handy, and many systems do that.
* Audit trails... Not your aneamic logs from an OS, but audit trails telling you who updated the document and when, often going back years. Very important in some environments.
* Approval/Review Cycles... Workflow is a common extension to many DMS implementations, adn allows for simple approval/review cycles in which the checking out/audit trail/versioning features are combined to allow one person and one person only to approve or review at a time. Quite handy, if done well.
* Records Management... Technically something else entirely, but records management often goes hand-in-hand with document management systems. Do all your invoices become unneeded after seven years? Fine - save 'em to the right place, and the DMS will handle that for you. Anything over seven years old simply gets removed, permanently, on a schedule. For you, this is useless. For a company GM's size, this saves hundreds of thousands of dollars every year.:-)
* Searching... As alluded to above, most DMS software has a full-text search capability these days, and if it's "in the box" then it's one less thing to have to implement in your IT strategy.
There's more, but you get the idea. It's basically there to control the way people work with documents, making sure that it's less likely to descend into a SNAFU where you can never find what you want...
And, of course, somewhere out there there's a developer who's got a career of experience that tells him you're wrong, because he's seen too many apps that had their nuderlying DB changed - painfully, of course - often for no good reason.
Maybe someone decided that MS SQL's license cost was cheaper, or that Oracle would be faster, or whatever.
And had that developer had encapsulation, he feels he'd have been fine.
*sighs*
No two situations are alike. No one product or technique does it all. Sometimes, I get the feeling that if we could all just get used to that and work together, we'd rule the damned world like we're supposed to.;-)
May your developers be smited when they suggest foolishness. And thanks for the new points of view!:-)
Against my wishes, Windows. Mostly Windows 2000, but we're slowly upgrading them to 2003.
I'm probably more familiar with Windows myself. But Linux license costs would be cheaper, and Linux can have a much lighter memory footprint - which can affect your performance and capacity management. The only real bummer with Linux is the case-sensitivity in the filesystem, which would no doubt throw our less-able helpdesk staff and cause much confusion for a while. This is one of ths sticky parts that stops us from moving to Linux - that and training the helpdesk staff!
I've worked with Domino on Solaris, AIX, OS/400 and Linux in the past. My preference was Solaris, but that's probably because it had some beefy hardware underneath it in the implementation I worked on. The OS/400 was nice, but I didn't get a huge amount of time with it. It tends to just work on OS/400, for some reason.;-)
Windows is definitely better in terms of layman-admin. That's a blessing and a curse. When I'm off, I get no questions asked about any platform issues - backups/restores go fine, for instance. With a *NIX OS, I just know that someone less able would get a restore request and just bounce it up to me because they couldn't figure it out or couldn't be bothered to. On the other hand, the fact that anyone can get their grubby paws on my servers through the pretence of backups/restores or similar is a bane, too. More than once I've been investigating things that could have been avoided had people not done stupid things. At this level, it's all a training & procedures issue, really.
In terms of power, Windows is more powerful. If you can be arsed to learn WMI and use VBScript to write long, complex scripts, that is. Whereas Linux gives you powerful and easy tools like grep, asar, cat and so forth - plus piping! Yay!
Ironically, this means that I find that in basic systems management the Linux boxes are much easier, but you can do almost anything on Windows - if you want to be a programmer. Which is almost exactly the opposite of the normal view of the situation...
Notes can often be under-resourced, though. Funny thing is that a Domino server will often struggle on happily through the very worst of configurations. That's great for keeping a service available when something breaks unexpectedly, but not so great if it's all the time.:-(
The other problem that makes Notes/Domino under-resourced is that it's often invisible to Management. They see either sexy new things or problematic old things, but never see MAJOR problems with Domino/Notes. In many shops I've seen, it's under-resourced simply because it sits there working and requiring far less attention than other products.
Sadly, it sounds like you either have a poor Notes team or an under-investment in the Notes infrastructure. Either way, that would kill just about any product, but I'll quit beating you over the head with that kind of statement now.;-)
Apologies for my late reply... Work has had a few power cuts and this has kept me busy. Thanks for your reply - it was informative, and I agree with some points on it and disagree with others.
I don't think you and I will ever agree on this subject, you know. We have fundamentally different experiences and views on this subject. Because of that, I'm not going to go into great detail point-by-point in my reply, as I suspect that we'd probably end up branching each point off multiple times, and Slashdot will close the discussion before we get even close to agreement.;-)
Relational data storage has its place. But the gigabytes of documents that my organisation has would be a complete pain to put into any relational storage system. Some data just isn't well suited to being stored in an RDBMS. You're not ever going to convince me otherwise, because I've seen too many badly implemented RDBMS-stored systems that I'm as biased against them as you are against Notes applications. To me, RDBMS means high development costs, horrific maintenance, low distribution potential and therefore high single-point-of-failure.
I've also seen lots of very well implemented Notes applications. I've seen it used to deliver information worldwide within hours of the information becoming available. I've seen it handle complex workflow that eased the administrative burden considerably in organisations. And I've seen it crash and burn when people did stupid things with it.
Notes cannot be replaced by Wikis, or Ruby on Rails, or anything else out on the market. But you expected me to say that, and you're scoffing right now.
I find it saddening that you've not had a good experience with Notes. For me, it's one of the most fascinating, capable and resilient peices of software ever written.
In the geek community, I'm in the minority. In business, that's far more debatable - with 120 million licences sold, people must be seeing value in Notes somewhere. Sadly, not here on Slashdot.:-(
Weird. Your opening comment shows you know that Notes is more than just email, yet you close by saying that you'd like to replace Notes with just a mail client.
OK, hotshot. What makes you think that Notes applications are nightmares in terms of maintenance? And quantify your concerns on scalability, please. Data quality? In what sense?
Bad applications can be written in any environment. VB has a terrible name in the industry, and we've all seen huge, bloated, unstable, nasty VB applications. But then again, VB has also been used very effectively by some. It's not the paintbrush, it's the artist - or so I hear.
Personally, I've seen Notes applications which took hundreds of thousands of records a week, sorted and sifted them, and then farmed them out around the world. The replication engine made that last part easy. That sounds like scalability to me - afforded by distributing the processing load worldwide, naturally.
Maintenance? Easy, because you have no DB schema to care about. Changes are much easier for the developer to handle, and don't require hours of extensive database maintenance - they're pretty much just a form change and perhaps a cleanup agent to remove any "retired" fields. Not only do I not see a maintenance nightmare, but I actually see a clear advantage.
Data quality? You've lost me. You're not one of those weird people who thinks all data should be relational, are you? I've never understood that. Some data and working processes lends themselves well to relational schemas. But most just don't. It's a restricting, cumbersome, maintenance intensive abstraction which is often unnecessary and just used out of habit. Microsoft tried for years to get a relational database backend to the way we store data - it was called WinFS, and failed despite their massive resources. And just about everything it promised me was something I could already do with a Notes Document Database - which is a standard template design that has shipped with Notes for at least ten years.
Usbaility on the client is a problem, yes. No getting around that. There's this odd catch-22 - IBM want to improve that. They really do. But for all you might say about it, there are lots of people in the workforce that are still a little afraid of computers, but that have learnt to use Notes. IBM know that a sudden change will not go down well with those users - so they want to minimise the shock. After all, you'd have to be mad to suddenly make massive UI changes to a familiar program like, say, a Word processor. Most corporations would go nuts at the training costs alone, and refuse to upgrade - surely? Usability has improved, and will continue to do so. But it will be a more gradual shift than many would like, simply so that everyone is brought along.
I'll leave the rest of your comment, as I have no issues with it apart from the closing comment. Thanks for your time!
Well, I'm not going to advise a rip-and-replace. That would be hypocritical of me.
But I am going to ask you to question just what your current mail system gives you.
With Domino, you get some of the best clustering in the business. Very high availability and a very robust security system, combined with a flexibility that's pretty much unmatched.
Now let's look at Notes itself. its mail functionality is much maligned, but there are some pretty neat features in there. The ability to change the basic mail database design, for instance, is very useful. We're currently scheduled to change a number of things in the mail client, to better meet our user's mail usage. For instance, tools to remove attachments automatically en masse, or tools to remove duplicate attachments (but leave the oldest occurance). Tools to make their mail a little easier to manage outside of attachments, like views which group all emails by the domain they were sent to/from.
Those are just a few examples for mail. Then there's the whole document database/workflow thing. That can be very useful for getting people who work at different sites to work together.
If your boss asks you what Notes can do for you, I suspect you won't have a decent answer. I don't mean that in a nasty way - I'm just stating a fact, based on your reaction there.
Oh, and the fact that you're considering lying to your boss is nice. It shows you're focused more on your personal prejudices than on providing value for money in your organisation. Good luck in your career in IT - you'll need it.
(Sorry. No offence intended, but without being harsh some people just don't see how irrational they're being... I know your remark was made in jest and all, but think how it looks to others!)
You seem to be misinformed. Yes, there's a program called Kill Notes. I've had Notes crash on me a few times - usually when I'm doing something very intensive - and not needed to run Kill Notes to get back up and running.
In fact, the need for Kill Notes is overstated.
But these "ghost tasks" - what the hell are you on about? What kind of technical term is that? What kind of ghosts are these? Is Elvis living inside my computer every time Notes crashes? If so, can I get my laptop a recording contract?
Allow me to explain. There are no such things as ghost tasks. There is, however, a solid architecture behind Notes. It has a UI side, and a backend side. The backend side does things like run agents, replicate data, and so forth. Sometimes, one of those tasks is active when the UI tanks. When Notes tries to start again, it finds that the background tasks have some files open that it wants, so won't start.
Annoying, I know. But then again, isn't this kind of architecture familiar? Where else do we often see background tasks that do the real work, simply being called by a UI? Could it be... UNIX? Yes, it could. UNIX was a major influence on the architecture of Notes - which is far more modular than you might suspect, and this has helped it adapt and change with the times very well. More so on the server side than the client side, I'll admit - SMTP/POP3/IMAP4/HTTP were just new modules written to run on the server, rather than being new functions in a monolithic program.
Anyway, we'd all like to see Kill Notes be unnecessary. As this Linux client is a port of the C/C++ code for Windows, I'd guess that there will need to be a port of Kill Notes as well. That's annoying, but if we want to be able to run agents locally and replicate in the background, then it's the price we'll have to pay...
I don't have time to deal with all your problems, but I'd like to make a point about reliability...
Restarting your Domino servers once a week is not right. Domino doesn't require that. That needs to be looked at.
So - do you actually know why they require restarts?
It might not be Domino.
Seriously.
I manage a number of Domino servers in my job. Some of them have to be restarted at least once a month, often because they've begun to degrade massively in their performance - or worse, they've crashed. The other servers are fine, and will run for months before they get restarted - and they're restarted because of OS patches or other maintenance, not because of problems on the Domino server.
Why is this? Well, one word - McAfee's Groupshield. The servers which run it require careful care and occasional kicking. The servers that don't need Groupshield on them don't have it, because it's a PITA which causes us grief.
We'd like to move away from Groupshield, but it requires lots of evaluation/testing/piloting, and we have other projects to be getting on with.
And don't think I'm singling out Groupshield. I've seen some abysmal backup programs, content security programs, and other third party add-ins in my time. Don't even think about mentioning ArcServe, for instance. Basically, lots of 3rd party software talks to Notes/Domino via the C/C++/COM/Java APIs it exposes - and not all of them are particularly well written.
Your experience with the Domino servers is not typical of others. There may be a specific cause for that - if not technical, then management or procedural. But I do find it very difficult to give your grievances ANY credit when you espouse rubbish like this that can so easily be explained, yet is related with so few details that it is difficult for anyone to easily check the facts.
Unfortunately, I'm on a cable provider that gives me a pitiful 128Kbs upstream, so I don't torrent much.
There's an odd thing about bittorrent, if you'll indulge me for a moment. I like P2P. I think it's a fantastic idea, which can really improve the internet. I have this great notion that something like ED2K can become a semi-permanent "distributed archive" for all commons media.
Yes, I'm nuts. But the thing is that ED2K or Gnutella have a more permanent presence than bittorrent. Most files on bittorrent right now will not be there next year. Most of the files on traditional P2P networks will be around for much longer. It's about lifetime of the medium, really.
So most of the time, I run an ED2K client. If I see a torrent I want to join - like a nice shiny new distro - then I'll kill ED2K for a short while, so that I can switch my bandwidth to the torrent. Good causes, and all that.
Why not uTorrent? Because Aureus is the second or third client I tried, and the one I'm now using. I have it on my always-on server box, where - just like the ED2K client - it's very useful.
But every now and again, I see a smaller torrent - for an 80Mb video, perhaps - that I'd like to fire off. I'm sure you can imagine how much more convenient that is with Opera 9 now. I just connect to the web control panel for the P2P app, throttle its traffic back, and then click on the torrent link. Job done, all without leaving the web browser that I first saw the torrent link in.
Conversely, whilst torrenting a large torrent, I might want to close my browser. So I'll use a dedicated torrent for that. Not to mention that whilst Opera is usually stable, it might crash - which would be a pain. A dedicated torrent client is just better for very large files, I think.
I suppose I may appear schizoid, but it works for me.;-)
Re:OMG!? "Opera-specific extensions"!?
on
Opera 9.0 Released
·
· Score: 1
On the desktop, you're absolutely right.
But note that Opera's extensions are for 2D games.
So this will allow web developers to create mobile games pretty easily? Games that require no downloads, no extensions - just a web page to be downloaded...
Anjd doesn't Opera have some kind of relationship with some silly little company called Symbian? The same Symbian that had 66.5% of smartphones in Q1 2006?
This is an extension which has HUGE potential. Don't even get me pointing out that Opera are supplying the browsers for Nintendo products...
You're looking at the wrong markets. The stagnant, unshifting, monopoly-based ones. Look at where there's huge growth in browsing, and you'll see Opera is way ahead of their competition - and these extensions aren't going to hurt that.
They didn't drop ICQ because it wasn't used, but because Mirabilis(?) kept changing the ICQ protocol to get rid of non-ICQ clients. Opera got tired of having to chase a moving spec, so they dropped it and eventually put an IRC client in instead.
My observation is that Opera wants to produce a great web browser that also contains unobtrusive, useful but lightweight Internet tools that some people expect from their "internet suite".
Their bittorrent client isn't the best in the world - but it works, it's fast and for a quick download it's far more useful than firing up another torrent client. Their chat (IRC) client isn't going to give mIRC sleepless nights, but it's fast and convenient. Their mail application is fast, powerful and small but subject to personal preference. Their RSS reader works fine for small numbers of RSS feeds, but lacks the organisational finesse of a purpose-built reader.
But the really nice thing with Opera is that all of these things add very little to the footprint, yet are there if you want them. Personally, I use Trillian for my IM needs and The Bat! for email, and serious torrenting will still be done with Azureus. But Opera's RSS reader is great for my needs, and if I'm just quickly downloading a smaller torrent why should I start a second bit of software?
Anyway, gotta go download O9 and install it, as I'm still running the beta...;-)
I'd just like to point out that Windows NT was, on first release, also lacking in compatibility just as OS/2 was.
They both used compatbility layers - OS/2 ran Windows code itself in a special VDM, and unsurprisingly enough so did Windows NT. In Windows NT, the VDM is called "Windows on Windows", or "WOW". It can easily be seen in your processes list in the Task Manager when you're running a 16-bit Windows app - hte task name would be "wowexec.exe", and your 16-bit apps will hand underneath it.
In both cases, the VDM would pass the calls made back to the underlying OS for processing, and in both systems if one Win16 program died it would often take out the entire VDM, killing all other 16-bit processes in one fell swoop.
The early WOW in NT was OK, but many 16-bit apps wanted to do things that just weren't acceptable in a 32-bit OS and therefore quite a few programs wouldn't run properly under it. You would most likely find that programs which failed under OS/2's VDM would also fail under WinNT's WOW systems. In many cases, it was a specific module of the program that was broken due to bad programming - not being able to print or use print previews was a common failure, for instance.
Microsoft realised that this compatibility wouldn't be enough, and pushed forwards with a project named Chicago. That then became Windows 4.0, and then became Windows 95 by the time it was lunched. Windows 95 had much greater compatibility with older Win16 apps because it wasn't as strict as Windows NT in its upholding of system integrity. It had a compromised architecture to do that, however. I could talk about how crap Windows 95 was for ages - but at the end of the day, Microsoft's marketing and their positioning of it as the consumer OS meant that people went out and re-wrote their apps using the Win32 API.
The Win32 API is what Windows 95 and Windows NT truly share. Windows 2000/XP could never have happened without Windows 95, and I suppose we should be grateful for that in many ways - I'd rather work with Win2K/WinXP than any Win9x machine.
Incidentally, the similarities I note between OS/2 and Windows NT aren't coincidence. Windows NT was orginally OS/2 version 3.0, and retained a few error messages that betrayd that heritage even until Windows NT 4.0's days.
First off, I don't think everyone will be running out and buying Windows XP anytime soon. Why? Because it really is unnecessary for most. The expenditure isn't justified.
I worked for a company in the UK that did the outsourced support for Windows 95. I saw it from beta onwards. I had a line to MS that I could use to get questions answered.
I though Windows 95 didn't have a hope in hell of getting anywhere. Its architecture was crap, it was unstable, it sucked resources up like a hoover in overdrive... It looked OK, but I just couldn't see why a user would move up to Windows 95.
I reasoned that for the vast majority of users, there would be no benefit to moving. Most of them write short documents or use small spreadsheets. How many people were ACTUALLY having problems with resources under Wndows 3.x? And those few that did have problems could always run under WinNT instead...
I reckoned without two things:
Users are stupid
Microsoft has great marketing
I saw people go into PC World at midnight on the day of release, and buy an "upgrade bundle" of Windows 95 and 8Mb or 16Mb of additional RAM. And in those days, RAM wasn't cheap.
People were spending up to 300 pounds just to run Windows 95.
I had this contant vision of users fititng their RAM, doing the upgrade, finishng it and then lookign at the screen. They click on the Start button. They "oooh!" and "aaah!" at it for a while. And then they start Word, and it runs no faster. Maybe even slower. But by this time, they're not going to admit they've wasted money. They're happy with it. Even if they did gain nothing except a documents menu and an emptier bank balance. (And the documents menu is duplicated with the MRU list on the Word file menu anyway, but never mind that.)
The average user gained nothin initially. And by the time Windows 95 was a viable platform, they still gained little. To really gain, they had to buy a new machine, with hardware designed for 95 and powerful enough to run software designed for 95.
Windows XP is the same. Most machines out there are under-specced for it. (It requires 128Mb of RAM to work well, IMHO.) The only difference is that, being based on Windows 2000, Windows XP should be stable. But the home edition lacks the security features. The new interface will make people "oooh!" and "aaah!" a bit, and then they'll rationalise their investment by appreciating the new colour scheme. (Blue! How, um, blue! Very. Blue.)
Microsoft is going to throw money at marketing this thing. People will by it. Nothing can stop that, because the only way is to educate people not to do it. But none of the media will do that - to tell people they won't need Windows XP would be a wonderful way to never see a pre-release or beta ever again, for any computer magazine. Or website. Or TV program. Microsoft will pull all the stops.
I never believed it could be done the first time.
I admit I was wrong, and I'm humbled by the experience. I've learnt my lesson - Never Underestimate Microsoft.
Being a Lotus Domino bigot, I'd recommend that over AOL any day.
But it is, as has been pointed out, not just the email client that's the problem.
The lack of any kind of calendaring and scheduling system is provbably what will hit them hardest operationally. If they weren't using it already, it won't be so bad - but decent calendaring and scheduling can save a company lots of time - and therefore lots of money. Imagine having to email each person individually to find out when they're free, and then collate the results and send out invitations...:-(
I'd hope that the AOL servers are reliable - they run a large chunk of their business, after all. But can they handle the scalability issues that may come up? Joe Bloggs with his consumer AOL account can afford to pull his email down from the server onto his PC - so indexing the mailbox is a simple affair. But for the Time Warner employees, it's not so neat a proposition... Firstly, I'd want my mail stored on a central server for backup purposes. Secondly, there's that "access from out of the office" that's touted in the article - that's nice, but it's only going to work for new mail unless they keep mail on the servers.
And have you ever seen how much email businesses can generate? More than AOL are comfortable with a normal user having in their inbox, certainly. After a year or two, some of their people may have a few thousand business emails - all of which they need to keep for legal reasons etc...
Finally, I suppose I'd like to wheel out the managability issue. I have no idea what AOL's back end is like, but I'm willing to bet it's probably not set up for global business usage. It's set up so that Joe Bloggs can get his email reliably. How do they plan to manage this system without either causing problems for their customers or for their employees? How do they plan to have a company address list? AOL have lots and lots of accounts. Will the next John Smith hired by Time Warner have to be jsmith264@aol.com?
This just seems wierd. The report is very vague on the back end, but I hope they're implementing a seperate one to their normal systems. Otherwise they're going to be the laughing stock of business...
End users are typically most impressed by the following features:
Ability to differentiate between calendar entry types - e.g. Appointment (Normal calendar entry), Meeting (Calendar entry that is also sent to others so that they can choose to place same entry into their calendar), Event (All day calendar entry, usually used for holidays/days off), Reminder (Start time is same as end time - no time marked as being used, as it's only there to remind you of something) and Anniversary (A reminder which repeats anually or even less frequently).
Creating a calendar entry should automatically mark their time as bsy for the duration of that entry, unless it's a Reminder or Anniversary. Or unless they choose to "pencil in" the item, in which case it's nor confirmed so it's not advertised to other users
Ability to look to other user's free/busy time when booking meetings
Ability to schedule repeating calendar entries - must be flexible - e.g. options like every N days, every day of week, every Nth day of month. Also the ability to move the appointment to friday/monday if it falls on a weekend to be incorporated here.
Ability to look at other people's calendars
Ability to mark calendar entries as private, so that other people won't see them when they look at your calendar. (The time tey take should still be marked as busy unless otherwise specified by the user, though.)
Ability to look at calendar using the following views: Daily, weekly, 5-day weekly, fortnightly, monthly, yearly planner
Ability to categorise your appointments
Ability to set reminders for your appointments
Ability to email reminders for your appointments
If you're doing anything with to-dos, integrating them into the calendar is nice
Conflicting entries must be marked clearly in all views. Checking for conflicts before you accept an invitation to a meeting/create a new calendar entry is also a must.
The administrative team should be able to create Rooms and Resources, which can be invited to meetings in the same way as people. This helps for scheduling of rooms, and also for things like projectors etc. Normally, booking should be done automatically on a first-come first-served basis, but you should be able to designate someone as the "owner" of each room or resource's calendar, so that they can confirm or deny bookings if necessary.
I'm acually coming from a Lotus Domino perspective, but if you put those features in you'll duplicate most of the important features of Domino's Calendaring and Scheduling systems. And the Yearly Planner view is one that Domino doesn't have, but users are crying out for...
One of the most impressive parts of Domino's C&S systems is the sheer scalability of it. You can have huge installations, yet free time lookups are easily handled by the system, even across WANs. You'll need some kind of referal system to handle this kind of stuff, otherwise it'll never fly in an enterprise. You can't have people's clients trying to cross the networks, y'see - but the servers will probably have access across WAN links to talk to each other. So almost all your free time stuff needs to be "referable" at the server side.
Also, you'll have noted that free time notation is seperate from the actual calendar. Free time should be stored somewhere else other than in the user's calendar, to make it easily scalable. It helps increase cache hits on the server, if nothing else. There would be nothing slower than having to open 20+ people's calendars to retrieve their free time information when booking a meeting with them. If it's all in one database, you're sorted then. If you're putting it all in one database anyway, make sure that free time is stored seperately in a table of its own. This should do the trick.
Note that free time is seperated from the actual entries anyway - sometimes you really do just want to pencil in an appointment, but not mark yourself as busy. Whenever we're asked why this feature is there, we can never think of a suitable example of why. But the person asking us usually gets back to us within a week with their own example...;-)
Having seen the code that Lotus uses in their Calendaring/Scheduling systems, I have to say that the hardest thing to get right is the repeating appointments part. Good luck!
We get the same concerns as you seem to have in the US.
We also had coverage of Napster, but the coverage was very low-key. There's been lots of "debate" in the computing press, but less in the mass media - this is probably because we don't have the cheap access that the US seems to have.
Without wishing to whinge, when you're paying per minute for your connection to your ISP, downloading entire albums does not become a hobby.;-)
When we start getting better penetration in the broadband market, we'll start seeing all the articles you've had being recycled into our mass media. But until then, I don't expect it'll fuss us much.
"Would Notes be a good thing if it was written right?"
It's written fairly well considering the scale of the product. And unlike some other companies, Lotus is commiteed to putting out fixes as quickly as possibly - with maintenance updates and quaterly maintenance releases to ensure that bugs hang around for as little as possible - and all that from a product that runs on multiple platforms.
"What does it really do that email, news and an address book can't? Hey! Don't we have all those already?"
Groupware. Which is a little more than email, news and an address book.
It allows workflow, so that documents you create can be routed to the correct people for approval.
It allows indexing of all those documents, so that you can find the one you wanted by a quick and easy search.
It allows security on the documents created, which is very important in a business environment.
And probably most importantly, it allows all of these features to be replicated around multiple servers, in a fast and efficient manner.
I think that Domino using Linux as a server platform is probably a good thing, but it remains to be seen how many companies will take up the option - after all, they can also run Domino on AIX, Solaris, HP-UX, Windows NT (Intel and Alpha), OS/2, OS/390 and OS/400. So we in the Domino world already have a good choice of platforms anyway.
Slashdot Mirror
When converting?
Well, yes, that will be the most common issue. But OOXML is supposed to open up documents for easy, cheap creation and manipulation by third parties. It's Microsoft's response to the ODF claim that now, you don't need the application which generated the data file.
Why is this an advantage? Well, imagine that you have a webserver serving financial quotes, and want to generate those quotes on the fly using the very latest data. Now you can output those quotes as documents quickly and easily, because you have the spec, right?
(Pedantically, yes you might choose to use PDF because it's "non-modifiable". I have a copy of WordPerfect X3 that allows roundtrip editing of PDFs. I have PDF cracking software that removes passwords/locks. And I have a copy of Acrobat. I'll modify your PDF if I want to. If you want to ensure your quote remains secure, then either don't give them the file or keep a copy of it for comparison later... Now back to the example.)
With ODF, outputting the file is easy. Same with OOXML. They're about equal for new documents.
What if your app needed instead to read old documents for some reason? Perhaps it's looking for links into your CRM system, using hints like the text before "yours sincerely" or for text which is right-formatted at the top of a page?
So to make this easier, you bulk convert your old data to OOXML. And then set your agent loose on the data.
Now what does useWord97LineBreakRules mean to you? Formatting is important in this context. It's how you're trying to recognise data. What the heck is a Word 97 Line Break Rule? Apparently, it refers to Far Eastern language blocks. Does it explain the weird formatting in all your RTL formatted paragraphs? Is this why the program works on documents from your Western offices but not ones from the Eastern offices?
A specification's job is to tell you not only that something exists, but also what it's for and what is does. Too often, Microsoft wave the "it's old, don't use it" wand in their OOXML spec, and whilst that's fine for new documents it's an appalling disservice to the documents you already have.
Of course, this is to Microsoft's advantage anyway. Having read about the spec, I plan to try and read it. But I think that I'll stick to OLE automation when it comes to manipulating Office documents, because the OLE/COM interfaces are better documented and better supported. And they have the advantage of letting Word figure out what the heck useWord97LineBreakRules means, rather than them having to do it.
This is probably what Microsoft want. Every application which reads and writes OOXML files natively and isn't part of Office is, to them, a potential lost Office sale. Why go out of their way to support that? OOXML sets the bar for using their XML suitably high, encouraging developers to use the existing OLE/COM interface rather than use the XML.
(And in my job I maintain a small app which uses OLE/COM to scrape data from an Excel spreadsheet that the user provides, so I'm fairly sure that OLE/COM would be easier than using the XML. Why did I use OLE/COM? Because the users tend to prepare the data in Excel anyway, so it cuts down on the steps required. I'd rather pull it from CSV or XML if I had the choice, but Excel is more convenient for the users on the whole, and prevents me from having to explain what File -> Save As does over and over again. And most importantly, because someone else wrote the core of the app, and I inherited it like that later. I've just been tweaking it as necessary. *grins*)
To go back to my example - who would want to scan their old documents and put them into a CRM system as possible related items? Well, I bet most businesses would be open to the idea. Until they see the cost. I'd also bet that it would be cheaper to accomplish with ODF documents than it would OOXML documents, because of the kinds of issues I've mentioned. In that regard, OOXML will actually hold back the IT industry - it will prevent cool things from being
Looks like he posted the wrong link - try this one:o kup/Open%20Secure%20Password%20Repository
http://www.openntf.org/projects/pmt.nsf/ProjectLo
Nice link. :-)
:-(
I work for a UK government-funded body, so we get the same sort of advice. It's all good, but selling it to users is pretty difficult at first.
I might just compare that link with our advice, and update accordingly. Thanks!
Good question.
;-)
:-)
It's about control and structure.
The usual question is "why can't I just use our shared mapped drives?" - so here's what you DON'T get from shared mapped drives that you do get from a Document Management System (DMS):
* Metadata... Basic metadata on the document which can help searching, and can sometimes be sorted upon etc. The metadata often varies with the "document type" - so tender documents/procurement documents have an Account field, where meeting minutes instead have an Attendees field. Yes, this takes more time to fill in when saving a document into a DMS. This is why users hate the DMS. Business loves it, of course, because it makes things easy to find years later.
* Structure... You create the overall structure, and nobody can change it. We've all seen file shares that have had no control - they become an impenetrable mess of folders, because everyone has their own slightly different filing system they're adhering to. DMS software allows an organisation to enforce just one filing system. Users hate that, too.
* Conflict Prevention... Most DMS software has the concept of "checking out" a document, just like you would check out a book at the library. Whilst you have that document checked out, everyone can see you're working on it - and nobody else can check it out. This prevents two idiots^Wusers from applying changes to the same document. Checking a document out also allows for an audit trail to be built.
* Versioning... Beyond the versioning that you get in Word - this is literally keeping a copy of every version that was checked in. You can usually also add a metadata comment for each vesrion when you check it in, to say what you changed. Often, you can even do this for each draft. Oh, by the way, being able to mark documents as either drafts or versions is also handy, and many systems do that.
* Audit trails... Not your aneamic logs from an OS, but audit trails telling you who updated the document and when, often going back years. Very important in some environments.
* Approval/Review Cycles... Workflow is a common extension to many DMS implementations, adn allows for simple approval/review cycles in which the checking out/audit trail/versioning features are combined to allow one person and one person only to approve or review at a time. Quite handy, if done well.
* Records Management... Technically something else entirely, but records management often goes hand-in-hand with document management systems. Do all your invoices become unneeded after seven years? Fine - save 'em to the right place, and the DMS will handle that for you. Anything over seven years old simply gets removed, permanently, on a schedule. For you, this is useless. For a company GM's size, this saves hundreds of thousands of dollars every year.
* Searching... As alluded to above, most DMS software has a full-text search capability these days, and if it's "in the box" then it's one less thing to have to implement in your IT strategy.
There's more, but you get the idea. It's basically there to control the way people work with documents, making sure that it's less likely to descend into a SNAFU where you can never find what you want...
Heh. Thanks!
;-)
:-)
And, of course, somewhere out there there's a developer who's got a career of experience that tells him you're wrong, because he's seen too many apps that had their nuderlying DB changed - painfully, of course - often for no good reason.
Maybe someone decided that MS SQL's license cost was cheaper, or that Oracle would be faster, or whatever.
And had that developer had encapsulation, he feels he'd have been fine.
*sighs*
No two situations are alike. No one product or technique does it all. Sometimes, I get the feeling that if we could all just get used to that and work together, we'd rule the damned world like we're supposed to.
May your developers be smited when they suggest foolishness. And thanks for the new points of view!
Phil
Against my wishes, Windows. Mostly Windows 2000, but we're slowly upgrading them to 2003.
;-)
I'm probably more familiar with Windows myself. But Linux license costs would be cheaper, and Linux can have a much lighter memory footprint - which can affect your performance and capacity management. The only real bummer with Linux is the case-sensitivity in the filesystem, which would no doubt throw our less-able helpdesk staff and cause much confusion for a while. This is one of ths sticky parts that stops us from moving to Linux - that and training the helpdesk staff!
I've worked with Domino on Solaris, AIX, OS/400 and Linux in the past. My preference was Solaris, but that's probably because it had some beefy hardware underneath it in the implementation I worked on. The OS/400 was nice, but I didn't get a huge amount of time with it. It tends to just work on OS/400, for some reason.
Windows is definitely better in terms of layman-admin. That's a blessing and a curse. When I'm off, I get no questions asked about any platform issues - backups/restores go fine, for instance. With a *NIX OS, I just know that someone less able would get a restore request and just bounce it up to me because they couldn't figure it out or couldn't be bothered to.
On the other hand, the fact that anyone can get their grubby paws on my servers through the pretence of backups/restores or similar is a bane, too. More than once I've been investigating things that could have been avoided had people not done stupid things. At this level, it's all a training & procedures issue, really.
In terms of power, Windows is more powerful. If you can be arsed to learn WMI and use VBScript to write long, complex scripts, that is. Whereas Linux gives you powerful and easy tools like grep, asar, cat and so forth - plus piping! Yay!
Ironically, this means that I find that in basic systems management the Linux boxes are much easier, but you can do almost anything on Windows - if you want to be a programmer. Which is almost exactly the opposite of the normal view of the situation...
As I said, that's wierd.
:-(
;-)
Notes can often be under-resourced, though. Funny thing is that a Domino server will often struggle on happily through the very worst of configurations. That's great for keeping a service available when something breaks unexpectedly, but not so great if it's all the time.
The other problem that makes Notes/Domino under-resourced is that it's often invisible to Management. They see either sexy new things or problematic old things, but never see MAJOR problems with Domino/Notes. In many shops I've seen, it's under-resourced simply because it sits there working and requiring far less attention than other products.
Sadly, it sounds like you either have a poor Notes team or an under-investment in the Notes infrastructure. Either way, that would kill just about any product, but I'll quit beating you over the head with that kind of statement now.
I hope it gets fixed soon!
Apologies for my late reply... Work has had a few power cuts and this has kept me busy. Thanks for your reply - it was informative, and I agree with some points on it and disagree with others.
;-)
:-(
I don't think you and I will ever agree on this subject, you know. We have fundamentally different experiences and views on this subject. Because of that, I'm not going to go into great detail point-by-point in my reply, as I suspect that we'd probably end up branching each point off multiple times, and Slashdot will close the discussion before we get even close to agreement.
Relational data storage has its place. But the gigabytes of documents that my organisation has would be a complete pain to put into any relational storage system. Some data just isn't well suited to being stored in an RDBMS. You're not ever going to convince me otherwise, because I've seen too many badly implemented RDBMS-stored systems that I'm as biased against them as you are against Notes applications. To me, RDBMS means high development costs, horrific maintenance, low distribution potential and therefore high single-point-of-failure.
I've also seen lots of very well implemented Notes applications. I've seen it used to deliver information worldwide within hours of the information becoming available. I've seen it handle complex workflow that eased the administrative burden considerably in organisations. And I've seen it crash and burn when people did stupid things with it.
Notes cannot be replaced by Wikis, or Ruby on Rails, or anything else out on the market. But you expected me to say that, and you're scoffing right now.
I find it saddening that you've not had a good experience with Notes. For me, it's one of the most fascinating, capable and resilient peices of software ever written.
In the geek community, I'm in the minority. In business, that's far more debatable - with 120 million licences sold, people must be seeing value in Notes somewhere. Sadly, not here on Slashdot.
Weird. Your opening comment shows you know that Notes is more than just email, yet you close by saying that you'd like to replace Notes with just a mail client.
OK, hotshot. What makes you think that Notes applications are nightmares in terms of maintenance? And quantify your concerns on scalability, please. Data quality? In what sense?
Bad applications can be written in any environment. VB has a terrible name in the industry, and we've all seen huge, bloated, unstable, nasty VB applications. But then again, VB has also been used very effectively by some. It's not the paintbrush, it's the artist - or so I hear.
Personally, I've seen Notes applications which took hundreds of thousands of records a week, sorted and sifted them, and then farmed them out around the world. The replication engine made that last part easy. That sounds like scalability to me - afforded by distributing the processing load worldwide, naturally.
Maintenance? Easy, because you have no DB schema to care about. Changes are much easier for the developer to handle, and don't require hours of extensive database maintenance - they're pretty much just a form change and perhaps a cleanup agent to remove any "retired" fields. Not only do I not see a maintenance nightmare, but I actually see a clear advantage.
Data quality? You've lost me. You're not one of those weird people who thinks all data should be relational, are you? I've never understood that. Some data and working processes lends themselves well to relational schemas. But most just don't. It's a restricting, cumbersome, maintenance intensive abstraction which is often unnecessary and just used out of habit. Microsoft tried for years to get a relational database backend to the way we store data - it was called WinFS, and failed despite their massive resources. And just about everything it promised me was something I could already do with a Notes Document Database - which is a standard template design that has shipped with Notes for at least ten years.
Usbaility on the client is a problem, yes. No getting around that. There's this odd catch-22 - IBM want to improve that. They really do. But for all you might say about it, there are lots of people in the workforce that are still a little afraid of computers, but that have learnt to use Notes. IBM know that a sudden change will not go down well with those users - so they want to minimise the shock. After all, you'd have to be mad to suddenly make massive UI changes to a familiar program like, say, a Word processor. Most corporations would go nuts at the training costs alone, and refuse to upgrade - surely?
Usability has improved, and will continue to do so. But it will be a more gradual shift than many would like, simply so that everyone is brought along.
I'll leave the rest of your comment, as I have no issues with it apart from the closing comment. Thanks for your time!
Well, I'm not going to advise a rip-and-replace. That would be hypocritical of me.
But I am going to ask you to question just what your current mail system gives you.
With Domino, you get some of the best clustering in the business. Very high availability and a very robust security system, combined with a flexibility that's pretty much unmatched.
Now let's look at Notes itself. its mail functionality is much maligned, but there are some pretty neat features in there. The ability to change the basic mail database design, for instance, is very useful. We're currently scheduled to change a number of things in the mail client, to better meet our user's mail usage. For instance, tools to remove attachments automatically en masse, or tools to remove duplicate attachments (but leave the oldest occurance). Tools to make their mail a little easier to manage outside of attachments, like views which group all emails by the domain they were sent to/from.
Those are just a few examples for mail. Then there's the whole document database/workflow thing. That can be very useful for getting people who work at different sites to work together.
If your boss asks you what Notes can do for you, I suspect you won't have a decent answer. I don't mean that in a nasty way - I'm just stating a fact, based on your reaction there.
Oh, and the fact that you're considering lying to your boss is nice. It shows you're focused more on your personal prejudices than on providing value for money in your organisation. Good luck in your career in IT - you'll need it.
(Sorry. No offence intended, but without being harsh some people just don't see how irrational they're being... I know your remark was made in jest and all, but think how it looks to others!)
Ah, good ol' Kill Notes.
You seem to be misinformed. Yes, there's a program called Kill Notes. I've had Notes crash on me a few times - usually when I'm doing something very intensive - and not needed to run Kill Notes to get back up and running.
In fact, the need for Kill Notes is overstated.
But these "ghost tasks" - what the hell are you on about? What kind of technical term is that? What kind of ghosts are these? Is Elvis living inside my computer every time Notes crashes? If so, can I get my laptop a recording contract?
Allow me to explain. There are no such things as ghost tasks. There is, however, a solid architecture behind Notes. It has a UI side, and a backend side. The backend side does things like run agents, replicate data, and so forth. Sometimes, one of those tasks is active when the UI tanks. When Notes tries to start again, it finds that the background tasks have some files open that it wants, so won't start.
Annoying, I know. But then again, isn't this kind of architecture familiar? Where else do we often see background tasks that do the real work, simply being called by a UI? Could it be... UNIX? Yes, it could. UNIX was a major influence on the architecture of Notes - which is far more modular than you might suspect, and this has helped it adapt and change with the times very well. More so on the server side than the client side, I'll admit - SMTP/POP3/IMAP4/HTTP were just new modules written to run on the server, rather than being new functions in a monolithic program.
Anyway, we'd all like to see Kill Notes be unnecessary. As this Linux client is a port of the C/C++ code for Windows, I'd guess that there will need to be a port of Kill Notes as well. That's annoying, but if we want to be able to run agents locally and replicate in the background, then it's the price we'll have to pay...
I don't have time to deal with all your problems, but I'd like to make a point about reliability...
Restarting your Domino servers once a week is not right. Domino doesn't require that. That needs to be looked at.
So - do you actually know why they require restarts?
It might not be Domino.
Seriously.
I manage a number of Domino servers in my job. Some of them have to be restarted at least once a month, often because they've begun to degrade massively in their performance - or worse, they've crashed.
The other servers are fine, and will run for months before they get restarted - and they're restarted because of OS patches or other maintenance, not because of problems on the Domino server.
Why is this? Well, one word - McAfee's Groupshield. The servers which run it require careful care and occasional kicking. The servers that don't need Groupshield on them don't have it, because it's a PITA which causes us grief.
We'd like to move away from Groupshield, but it requires lots of evaluation/testing/piloting, and we have other projects to be getting on with.
And don't think I'm singling out Groupshield. I've seen some abysmal backup programs, content security programs, and other third party add-ins in my time. Don't even think about mentioning ArcServe, for instance. Basically, lots of 3rd party software talks to Notes/Domino via the C/C++/COM/Java APIs it exposes - and not all of them are particularly well written.
Your experience with the Domino servers is not typical of others. There may be a specific cause for that - if not technical, then management or procedural. But I do find it very difficult to give your grievances ANY credit when you espouse rubbish like this that can so easily be explained, yet is related with so few details that it is difficult for anyone to easily check the facts.
Unfortunately, I'm on a cable provider that gives me a pitiful 128Kbs upstream, so I don't torrent much.
;-)
There's an odd thing about bittorrent, if you'll indulge me for a moment. I like P2P. I think it's a fantastic idea, which can really improve the internet. I have this great notion that something like ED2K can become a semi-permanent "distributed archive" for all commons media.
Yes, I'm nuts. But the thing is that ED2K or Gnutella have a more permanent presence than bittorrent. Most files on bittorrent right now will not be there next year. Most of the files on traditional P2P networks will be around for much longer. It's about lifetime of the medium, really.
So most of the time, I run an ED2K client. If I see a torrent I want to join - like a nice shiny new distro - then I'll kill ED2K for a short while, so that I can switch my bandwidth to the torrent. Good causes, and all that.
Why not uTorrent? Because Aureus is the second or third client I tried, and the one I'm now using. I have it on my always-on server box, where - just like the ED2K client - it's very useful.
But every now and again, I see a smaller torrent - for an 80Mb video, perhaps - that I'd like to fire off. I'm sure you can imagine how much more convenient that is with Opera 9 now. I just connect to the web control panel for the P2P app, throttle its traffic back, and then click on the torrent link. Job done, all without leaving the web browser that I first saw the torrent link in.
Conversely, whilst torrenting a large torrent, I might want to close my browser. So I'll use a dedicated torrent for that. Not to mention that whilst Opera is usually stable, it might crash - which would be a pain. A dedicated torrent client is just better for very large files, I think.
I suppose I may appear schizoid, but it works for me.
On the desktop, you're absolutely right.
But note that Opera's extensions are for 2D games.
So this will allow web developers to create mobile games pretty easily? Games that require no downloads, no extensions - just a web page to be downloaded...
Anjd doesn't Opera have some kind of relationship with some silly little company called Symbian? The same Symbian that had 66.5% of smartphones in Q1 2006?
This is an extension which has HUGE potential. Don't even get me pointing out that Opera are supplying the browsers for Nintendo products...
You're looking at the wrong markets. The stagnant, unshifting, monopoly-based ones. Look at where there's huge growth in browsing, and you'll see Opera is way ahead of their competition - and these extensions aren't going to hurt that.
They didn't drop ICQ because it wasn't used, but because Mirabilis(?) kept changing the ICQ protocol to get rid of non-ICQ clients. Opera got tired of having to chase a moving spec, so they dropped it and eventually put an IRC client in instead.
;-)
My observation is that Opera wants to produce a great web browser that also contains unobtrusive, useful but lightweight Internet tools that some people expect from their "internet suite".
Their bittorrent client isn't the best in the world - but it works, it's fast and for a quick download it's far more useful than firing up another torrent client. Their chat (IRC) client isn't going to give mIRC sleepless nights, but it's fast and convenient. Their mail application is fast, powerful and small but subject to personal preference. Their RSS reader works fine for small numbers of RSS feeds, but lacks the organisational finesse of a purpose-built reader.
But the really nice thing with Opera is that all of these things add very little to the footprint, yet are there if you want them. Personally, I use Trillian for my IM needs and The Bat! for email, and serious torrenting will still be done with Azureus. But Opera's RSS reader is great for my needs, and if I'm just quickly downloading a smaller torrent why should I start a second bit of software?
Anyway, gotta go download O9 and install it, as I'm still running the beta...
I'd just like to point out that Windows NT was, on first release, also lacking in compatibility just as OS/2 was.
They both used compatbility layers - OS/2 ran Windows code itself in a special VDM, and unsurprisingly enough so did Windows NT. In Windows NT, the VDM is called "Windows on Windows", or "WOW". It can easily be seen in your processes list in the Task Manager when you're running a 16-bit Windows app - hte task name would be "wowexec.exe", and your 16-bit apps will hand underneath it.
In both cases, the VDM would pass the calls made back to the underlying OS for processing, and in both systems if one Win16 program died it would often take out the entire VDM, killing all other 16-bit processes in one fell swoop.
The early WOW in NT was OK, but many 16-bit apps wanted to do things that just weren't acceptable in a 32-bit OS and therefore quite a few programs wouldn't run properly under it. You would most likely find that programs which failed under OS/2's VDM would also fail under WinNT's WOW systems. In many cases, it was a specific module of the program that was broken due to bad programming - not being able to print or use print previews was a common failure, for instance.
Microsoft realised that this compatibility wouldn't be enough, and pushed forwards with a project named Chicago. That then became Windows 4.0, and then became Windows 95 by the time it was lunched. Windows 95 had much greater compatibility with older Win16 apps because it wasn't as strict as Windows NT in its upholding of system integrity. It had a compromised architecture to do that, however. I could talk about how crap Windows 95 was for ages - but at the end of the day, Microsoft's marketing and their positioning of it as the consumer OS meant that people went out and re-wrote their apps using the Win32 API.
The Win32 API is what Windows 95 and Windows NT truly share. Windows 2000/XP could never have happened without Windows 95, and I suppose we should be grateful for that in many ways - I'd rather work with Win2K/WinXP than any Win9x machine.
Incidentally, the similarities I note between OS/2 and Windows NT aren't coincidence. Windows NT was orginally OS/2 version 3.0, and retained a few error messages that betrayd that heritage even until Windows NT 4.0's days.
I though Windows 95 didn't have a hope in hell of getting anywhere. Its architecture was crap, it was unstable, it sucked resources up like a hoover in overdrive... It looked OK, but I just couldn't see why a user would move up to Windows 95.
I reasoned that for the vast majority of users, there would be no benefit to moving. Most of them write short documents or use small spreadsheets. How many people were ACTUALLY having problems with resources under Wndows 3.x? And those few that did have problems could always run under WinNT instead...
I reckoned without two things:
- Users are stupid
- Microsoft has great marketing
I saw people go into PC World at midnight on the day of release, and buy an "upgrade bundle" of Windows 95 and 8Mb or 16Mb of additional RAM. And in those days, RAM wasn't cheap.People were spending up to 300 pounds just to run Windows 95.
I had this contant vision of users fititng their RAM, doing the upgrade, finishng it and then lookign at the screen. They click on the Start button. They "oooh!" and "aaah!" at it for a while. And then they start Word, and it runs no faster. Maybe even slower. But by this time, they're not going to admit they've wasted money. They're happy with it. Even if they did gain nothing except a documents menu and an emptier bank balance. (And the documents menu is duplicated with the MRU list on the Word file menu anyway, but never mind that.)
The average user gained nothin initially. And by the time Windows 95 was a viable platform, they still gained little. To really gain, they had to buy a new machine, with hardware designed for 95 and powerful enough to run software designed for 95.
Windows XP is the same. Most machines out there are under-specced for it. (It requires 128Mb of RAM to work well, IMHO.) The only difference is that, being based on Windows 2000, Windows XP should be stable. But the home edition lacks the security features. The new interface will make people "oooh!" and "aaah!" a bit, and then they'll rationalise their investment by appreciating the new colour scheme. (Blue! How, um, blue! Very. Blue.)
Microsoft is going to throw money at marketing this thing. People will by it. Nothing can stop that, because the only way is to educate people not to do it. But none of the media will do that - to tell people they won't need Windows XP would be a wonderful way to never see a pre-release or beta ever again, for any computer magazine. Or website. Or TV program. Microsoft will pull all the stops.
I never believed it could be done the first time.
I admit I was wrong, and I'm humbled by the experience. I've learnt my lesson - Never Underestimate Microsoft.
Being a Lotus Domino bigot, I'd recommend that over AOL any day.
:-(
But it is, as has been pointed out, not just the email client that's the problem.
The lack of any kind of calendaring and scheduling system is provbably what will hit them hardest operationally. If they weren't using it already, it won't be so bad - but decent calendaring and scheduling can save a company lots of time - and therefore lots of money. Imagine having to email each person individually to find out when they're free, and then collate the results and send out invitations...
I'd hope that the AOL servers are reliable - they run a large chunk of their business, after all. But can they handle the scalability issues that may come up? Joe Bloggs with his consumer AOL account can afford to pull his email down from the server onto his PC - so indexing the mailbox is a simple affair. But for the Time Warner employees, it's not so neat a proposition... Firstly, I'd want my mail stored on a central server for backup purposes. Secondly, there's that "access from out of the office" that's touted in the article - that's nice, but it's only going to work for new mail unless they keep mail on the servers.
And have you ever seen how much email businesses can generate? More than AOL are comfortable with a normal user having in their inbox, certainly. After a year or two, some of their people may have a few thousand business emails - all of which they need to keep for legal reasons etc...
Finally, I suppose I'd like to wheel out the managability issue. I have no idea what AOL's back end is like, but I'm willing to bet it's probably not set up for global business usage. It's set up so that Joe Bloggs can get his email reliably. How do they plan to manage this system without either causing problems for their customers or for their employees? How do they plan to have a company address list? AOL have lots and lots of accounts. Will the next John Smith hired by Time Warner have to be jsmith264@aol.com?
This just seems wierd. The report is very vague on the back end, but I hope they're implementing a seperate one to their normal systems. Otherwise they're going to be the laughing stock of business...
I'm acually coming from a Lotus Domino perspective, but if you put those features in you'll duplicate most of the important features of Domino's Calendaring and Scheduling systems. And the Yearly Planner view is one that Domino doesn't have, but users are crying out for...
One of the most impressive parts of Domino's C&S systems is the sheer scalability of it. You can have huge installations, yet free time lookups are easily handled by the system, even across WANs. You'll need some kind of referal system to handle this kind of stuff, otherwise it'll never fly in an enterprise. You can't have people's clients trying to cross the networks, y'see - but the servers will probably have access across WAN links to talk to each other. So almost all your free time stuff needs to be "referable" at the server side.
Also, you'll have noted that free time notation is seperate from the actual calendar. Free time should be stored somewhere else other than in the user's calendar, to make it easily scalable. It helps increase cache hits on the server, if nothing else. There would be nothing slower than having to open 20+ people's calendars to retrieve their free time information when booking a meeting with them. If it's all in one database, you're sorted then. If you're putting it all in one database anyway, make sure that free time is stored seperately in a table of its own. This should do the trick.
Note that free time is seperated from the actual entries anyway - sometimes you really do just want to pencil in an appointment, but not mark yourself as busy. Whenever we're asked why this feature is there, we can never think of a suitable example of why. But the person asking us usually gets back to us within a week with their own example...
Having seen the code that Lotus uses in their Calendaring/Scheduling systems, I have to say that the hardest thing to get right is the repeating appointments part. Good luck!
We get the same concerns as you seem to have in the US.
;-)
We also had coverage of Napster, but the coverage was very low-key. There's been lots of "debate" in the computing press, but less in the mass media - this is probably because we don't have the cheap access that the US seems to have.
Without wishing to whinge, when you're paying per minute for your connection to your ISP, downloading entire albums does not become a hobby.
When we start getting better penetration in the broadband market, we'll start seeing all the articles you've had being recycled into our mass media. But until then, I don't expect it'll fuss us much.
- It allows workflow, so that documents you create can be routed to the correct people for approval.
- It allows indexing of all those documents, so that you can find the one you wanted by a quick and easy search.
- It allows security on the documents created, which is very important in a business environment.
- And probably most importantly, it allows all of these features to be replicated around multiple servers, in a fast and efficient manner.
I think that Domino using Linux as a server platform is probably a good thing, but it remains to be seen how many companies will take up the option - after all, they can also run Domino on AIX, Solaris, HP-UX, Windows NT (Intel and Alpha), OS/2, OS/390 and OS/400. So we in the Domino world already have a good choice of platforms anyway.