Ed Brill

Post a Comment

1. 1  Chad B.  | 8/4/2008 2:33:18 PM

   Sunglasses guy has "tool" written all over him. Too late to get the marketing dept. to submit a new graphic? It's bad enough that I would seriously hesitate to send any of our suits to this page, lest they get the wrong impression of new notes/domino.

   less "pray I never meet your daughter" and more app shots please . . .

1. 2  Keith Brooks http://www.vanessabrooks.com | 8/4/2008 2:35:43 PM

   This may be a landing page of some sort and perhaps the way it appears in the left column here, { Link } is how it should appear here as well.

   Or a note to Web content people:

   In the 1st paragraph would like to see the word Server after the Domino name so it is not confused with another client.

   Note Lotus Notes Client is stipulated although sort of implies a Lotus Notes Server exists.

   There are many people who never used it and may come now for MAC or Linux reasons, don't confuse them just because you and I know about Domino.

1. 3  Kevin Mort http://www.theglobalmind.com | 8/4/2008 2:40:57 PM

   Buzz buzz...what's that sound?

   There's a good reason the yellow & black of Lotus works. : )

   Now, where's my Lotusphere "yellow jacket" backpack from a couple years ago...

1. 4  John Turnbow http://www.recondite2.com | 8/4/2008 2:47:28 PM

   I love R8.5. The message is lost though. Needs more separation, pics, what these new features enable. I would not send my boss this link.

1. 5  Bruce http://elguji.com | 8/4/2008 2:57:27 PM

   Maybe Lotus needs to establish a "Marketing Design Partner" program so get feedback on ad campaigns, new web content, media etc. prior to it being ripped apart on edbrill.com.

1. 6  Richard Schwartz http://www.rhs.com/poweroftheschwartz | 8/4/2008 3:14:17 PM

   The description of DAOS needs a re-write.

   I.e., "a property that will help reduce the total cost of ownership"... Oy! It is enabled by setting a property, but it is not itself a property! It's a feature, or a service.

   Continuing on, "... by reducing redundant file attachments in a separate repository on the server". Yuck! Not only doesn't it actually say what it means, but it also manages to avoid using any of the buzzwords that would give people a clue what it's really talking about.

   How about "a feature that dramatically reduces storage requirements by enabling a new repository on the server to support single-instance storage of file attachments in messages and documents"

   Or, using a different buzzword and different wording, "a feature that uses a separate repository for file attachments on the server to enable de-duplication across messages and documents in order to achieve dramatic storage savings".

   And note: It's a "feature", not a

1. 7  tonyo  | 8/4/2008 3:25:46 PM

   At Lotusphere they talked all about how you could use AD for the directory instead the Domino directory. Did that get pulled?

1. 8  Volker Weber http://vowe.net | 8/4/2008 3:52:43 PM

   Class browser for Lotusscript got the most applause at the Lotusphere OGS. This site only talks about Xpages and web development. Gone as well?

1. 9  Alan Lepofsky http://www.alanlepofsky.net | 8/4/2008 4:18:09 PM

   Ed, can you please have IBM makes Lotus cool so that younger generations of iPod hugging college kids will want to use it.... oh wait, no don't do that, make sure the marketing stuff is all business like so the bosses like it, because they are not cool. ;-) And make sure IBM.com cares about Lotus, or wait... Can't win can you! ;-) BTW, when did IBM start paying Nathan to model for banner ads?

1. 10  Nathan T. Freeman http://nathan.lotus911.com | 8/4/2008 4:18:10 PM

   @8 - I think it's been publicized pretty broadly that the LS class browser slipped until 8.5.1. That's not exactly news anymore.

1. 11  Bruce http://elguji.com | 8/4/2008 5:02:25 PM

   Look at the first email message in the view. Could it be Luis's wife is trying to get a hold of him since he doesn't use his work email anymore? :-)

1. 12  Volker Weber http://vowe.net | 8/4/2008 5:23:22 PM

   > Anybody else missing their favourite feature? :-)

   A servlet engine not from the 90s?

1. 13  John Turnbow http://www.recondite2.com | 8/4/2008 6:58:24 PM

   Waiting on LotusScript? MMM.. At the last EView I was at one of the presenters asked how many people knew JAVA. No one, no one, raised their hands. That should be a pointer as to how to keep your loyal Lotus troops on board. I remember at Lotusphere only a few hands raised...

1. 14  Erik Brooks  | 8/4/2008 7:36:48 PM

   @13 - Ok, I gotta admit it: it's a good thing I wasn't drinking anything when I read that.

   I honestly hadn't been following the servlet stuff much. I started piping things to Tomcat a long time ago, but I always held out hope when I saw Bob Balaban's post "What if... better Java?"

   Are there any plans/rumors/etc. for the servlet engine?

1. 15  Nathan T. Freeman http://nathan.lotus911.com | 8/4/2008 8:02:18 PM

   @15 - Xpages runs on a brand new servlet engine. But you can't plug into it just yet. Hopefully that'll happen in the future.

   However, the motive to do so would be based pretty much entirely on a desire to do a REST/WebDAV API. If you simply want to support HTTP responses from a Java context without calling agents, Xpages will do that for you. You can deploy the JAR through a template if you know how to do it properly. I'll probably do a tutorial on that in the next two weeks or so.

1. 16  AR http://DAOS | 8/5/2008 4:45:47 AM

   I don't understand the fuss about DAOS. To me single instance storage is one of the main design mistakes of Exchange as it makes restoring mailboxes etc. far harder than it should be.

   Can anybody explain how DAOS is going to impact backups and restores of mail databases or enlighten me as to how DAOS is different from Exchange single instance storage.

   TIA

1. 17  Axel  | 8/5/2008 5:09:24 AM

   Its interesting to see how those old debates are indeed loosing its context. As Nathan said JSF is based on Servlets/JSP (or other template languages) so of course there is a servlet engine running. And today no sane person would start a project with raw servlets but with some kind of framework, of which JSF is one and for a lot of cases definitedly not the worst option.

   People complain for ages about a) complexity of Java and b) too many competing frameworks on Java.

   Now if IBM chooses a less low level solution like xPages on JSF as one clear framework choice, people want a raw servlet engine.

   IT journalism has that dilemma to be good at create plausible text for areas one is a complete noob. And in areas one is more expert the flaws get visible.

1. 18  Ben Poole http://benpoole.com | 8/5/2008 5:39:27 AM

   @18 I see no real debate here. Exposing the new servlet engine isn't a matter of great controversy as far as I'm concerned: the building blocks are there, why not take advantage?

   Sure, there are other priorities for the development team, but if it can happen one day, plenty of developers would be happy: there's nothing wrong with writing the odd 'raw' servlet now and then; too many Java frameworks are a case of "sledgehammer to crack a nut'.

1. 19  Nathan T. Freeman http://nathan.lotus911.com | 8/5/2008 6:44:35 AM

   @17 - "Can anybody explain how DAOS is going to impact backups and restores of mail databases or enlighten me as to how DAOS is different from Exchange single instance storage."

   Sure.

   Imagine you send a 10MB attachment to 10 people all on a single Domino server. Prior to DAOS, you would be storing 100MB, one instance in each NSF. And when you go to back up those NSFs, you would be storing the entire attachment inside each one of those NSFs. So if you have 10 nights of backups, you're now using 1000MB of backup space for a 10MB attachment.

   With DAOS, the attachment is stored on the server as a discrete file, and the NSF only stores a pointer to that file. With 10 nights of backups for the 10 recipients of that 10MB attachment, your backup storage consumption is still only 10MB. (Well, technically you've redundantly backed up the pointer, but that's something like 32-bytes per instance, so it's pretty trivial.)

   The failure of single instance stores in the past, whether on Domino or on Exchange, has really been about two things:

   1) The decision to put absolutely everything into one massive database store that becomes a single point of catastrophic failure;

   2) The inability of operating systems and backup solutions to work well with discrete units inside that single store.

   Since DAOS writes each attachment as a discrete file, there is no central data store to "get corrupted." There's no further logic to managing the files than what services the operating system already provides. Backups are easy, because the backup system knows to just look for changed files within that folder structure, just like any other file system. It's dramatically simpler, and it no longer becomes necessary for your backup solution to understand the Domino API. (At least, not for the sake of attachment backups.)

   Restoration *could* be slightly more complicated, in that if you want to restore a user's NSF from 60 days ago, you MIGHT also need to restore the attachment collection from 60 days ago. But there is a buffer period for the attachments even after the very last person deletes the link from their mail NSF -- and if memory serves you can set that buffer period for however long you like. If the attachment is still in the server's collection when you restore the individual NSF, it will find the link with no further effort. If the attachment has been purged, then you'll need to restore BOTH the mail NSF and the attachment folder from the same backup set.

   If you're really worried about it, set your buffer period to 20 years. Don't ever bother to remove attachments from the central store. You're not incrementally backing them up, and they're only stored once anyway, so the cost of retaining them is a tiny fraction of what it used to be.

1. 20  Axel  | 8/5/2008 6:57:05 AM

   @19 I see no real debate here, neither.

   All new java web projects I see, use one of those frameworks. Lotus does that too.

   The "sledgehammer to crack a nut" analogy does fit in corner cases, but not in the average of the total requirements of a project.

   Lotus has allways been kind of a framework for Enterprise C-programming.

   Or look at lotus xml apis. I used it a lot, but many Domino developers I see simply don't, because they don't see enough roi to digg into the details of xml + dom/sax apis.

   I guess nearly all techies would agree that only some times low level is simpler than higher level. Most times it is not.

   I am all for opening the existing servlet engine, but I find its plausible to first lay out the grand lines of a programming model closer to the business logic.

   I see chances high, that you actually agree.

1. 21  Erik Brooks  | 8/5/2008 7:03:47 AM

   @17 - The other major (and often overlooked) advantage of DAOS is the fact that it moves your attachments OUT of the NSFs.

   Even for attachments that aren't repeated across dbs -- where you won't get any extra storage relief -- DAOS helps to keep your NSFs small.

   Would you rather have:

   (1) 1 GB NSF + 60 GB of attachments at the OS level

   (2) 61 GB NSF

   I'll take #1 any day. Assuming the DAOS reliability is there (and it pretty much has to be, or it'll flop on its face upon launch) the smaller NSF will be faster in many ways than the larger one.

   And since you specify the DAOS storage path in the server doc you could use an entirely different drive - or even an entirely different server - as your DAOS store. I'm looking forward to moving our attachments to an inexpensive SAN, reserving our high-speed SAS RAID arrays for the NSFs themselves.

   You can read more technical discussion at the Lotus Domino Server team blog:

   { Link }

1. 22  Bernard  | 8/5/2008 7:28:15 AM

   @20 "It's dramatically simpler, and it no longer becomes necessary for your backup solution to understand the Domino API. (At least, not for the sake of attachment backups.)"

   But doesn't it also mean that those 'attached' files are no longer wrapped up by Domino security? That may or may not be an issue depending on what's in the attachment. It probably is not an issue, since people seem to care far less about security now than when Notes was first released.

1. 23  Nathan T. Freeman http://nathan.lotus911.com | 8/5/2008 7:40:38 AM

   "But doesn't it also mean that those 'attached' files are no longer wrapped up by Domino security?"

   Nope. They are locally encrypted with the server's ID. So they're only readable through the Domino API.

   That's the clever thing. The Backup system doesn't have to understand the contents in order to archive the file. It just handles it as a discrete unit. But even if you have OS-level access to the drive on the server, the file still doesn't do you any good unless you can use the server's ID to decrypt it.

   As always, physical and OS-level lockdown on your server is important for security.

1. 24  Henning Heinz  | 8/5/2008 8:16:28 AM

   DAOS requires transaction logging. Transactional logging is nothing new but there still seem to be installations that do not use it yet.

1. 25  Richard Schwartz http://www.rhs.com/poweroftheschwartz | 8/5/2008 10:35:34 AM

   @20 - re backups, it's fair to say that you are correct for any file-based backup solutions; but the jury is still out with respect to how Notes-aware backup solutions will be able to deal with DAOS.

1. 26  David Bell  | 8/5/2008 12:16:31 PM

   @27 - why did we not use one of the design personae images on the graphic ? Isn't part of the reason they exist to model and communicate actual usage of the product ?

1. 27  Brian Green  | 8/5/2008 3:06:15 PM

   @24 - here's hoping the anti-virus software does not randomly delete OS-level attachments. :(

1. 28  Erik Brooks  | 8/5/2008 5:38:24 PM

   @28 - Simply exclude the DAOS directory from your virus-scanning software.

   The only potential security disadvantage to DAOS is if you were relying on reader's fields to keep somebody out of specific attachments when they ALSO have OS file-system-level access.

   Then I would guess it *might* be possible that they could grab a DAOS-encrypted file and the server's ID file, set up another server, and attempt to read the DAOS file.

   But if they've got access to your server's OS-level data files AND your server ID file, you're pretty much handing them the keys anyway.

   Also keep in mind that DAOS is something to enable on a server-by-server basis, AND a db-by-db basis. So you can simply not use it if you don't want to.

1. 29  Steven  | 8/5/2008 7:36:55 PM

   @28: I'd hope your real-time scanning Domino-aware anti-virus software would have caught the problem before the messages were delievered and/or processed by DAOS. Of course the question does come up as to how you'd handle post-event scanning, such as when a viurs appears in the wild and the signature files are not available until messages are already delivered. We can handle that now, but will Domino-aware software be able to link the attachment back to the message? Something to hit our vendor up with now, I guess. Also what does the client see if their message had an attachment in DAOS that was somehow "lost" or deleted for what ever reason?

1. 30  Thilo Hamberger  | 8/6/2008 3:29:08 AM

   @20: Is it like R5 Shared Mail? Only this time we save the attachments directly at the OS level?

1. 31  Enrique Contreras  | 8/7/2008 3:14:52 PM

   Is there a place to put our "whislist" for Lotus Notes?

   Let me give you some of my wishes:

   * Multiple Notes ID at once -- Each database should remember which ID (file or UID/password combination) to use.

   * One single view or window for both, online mailbox and the archive database.

   * Extended: One single view or window for N databases of the same type (template).

   Kind regards,

   Enrique Contreras V.

1. 32  Nazeer Aval http://www.sbm.com.sa | 8/10/2008 12:25:32 PM

   @20 - read this article

   { Link }

1. 33  Fredrik  | 9/18/2008 1:16:43 PM

   Well, since everybody else

   * Be able to print and get binary data out of a java agent

   * Java server tasks documented and supported

   * Built in single sign-on with Active directory

   * Better control of attachments in documents (The saving and not saving within richtext fields)

   * INotes upload control official supported as a upload control

   * Spellchecker and image support in own apps with standard richtext fields

   * Programmable Symphony objects in client and webb