Nobody has explained the real reason why users shouldn't be trusted to add domains to a domain-wide spam blacklist, so I will: If you have 10 users who have subscribed to weekly mailings from acme.com, the one user who is too lazy to figure out how to unsubscribe properly will end up blocking the messages which the other 9 users still want to receive.

Sounds like FrankenServer

Agree w/ Kenneth

Good topic. Lousy title. Find a better one.

I agree with Ben. EM is a great topic. EM on Linux has very narrow appeal.

Fixed the link. Thanks. And you've already stated my better idea: additional sections. I'm not a UI designer, so trust me you don't want any further detail from me. But anything is better than a scrolling checkbox!

The whole per-core licensing model needs to be scrapped. Doing this would just make it more entrenched.

I believe that this is disabled because, depending on server settings, mail can be addressed to a user by just first or last name. When this setting is in effect, allowing users to edit their own first or last names would create an easy path for a denial-of-service attack. I.e., change your first or last name to match your CEO's name, and suddenly all mail to him is rejected.

The problem with this idea is that it doesn't go far enough. Departmental address books should be tied in with a self-service system that lets you create applications (e.g., blogs, wikis, doclibs, address books, and more) within a connected hierarchy of personal, departmental, divisional, and corporate applications that allow easy creation of content at the appropriate organizational level, and then facilitates creation of links and managing access for sharing across organizational levels.

Adding numbers to the list is just a band-aid on a bad UI.

A whole new feature just for managing dead mail isn't the way. Enhancements to server-based mail rules to prevent mail from going dead in mail.box in the first place is something I would support.

The behavior of AppendItemValue has been the same for 15 years, and there are programs that depend on it. I would vote for a new method, but not a change to the existing method.

I've been wanting this for more than ten years. What is needed is a separation of the the key pair used for authentication and signature from the key pair used for decryption so that a user ID can contain multiple private keys for decryption. Customers currently work around this by sharing a common ID file for access to encrypted messages in shared mailboxes, but this loses authentication of which real person acts on a message. A user should be able to read an encrypted message with a shared private key, but sign a reply to it with his own private key!

Lotus Domino 7 Application Development
Lotus Domino Domain Monitoring
Security Considerations in Notes and Domino 7: Making Great Security Easier to Implement
IBM Lotus Notes and Domino 8 Deployment Guide
Domino 7 Performance Tuning Best Practices to Get the Most Out of Your Domino Infrastructure
Migrating from Microsoft Exchange 2000/2003 to Lotus Notes and Domino 7
Understanding Lotus Notes Smart Upgrade
Lotus Notes and Domino 7 Enterprise Upgrade Best Practices
Building Composite Applications

I'm afraid there's no such thing as a standard phone number format. I don't see how this could ever work in a multinational company.

The trouble with Trigger Happy is that it's not part of the database design.

Hide-whens are bound to paragraph, not to a field. A paragraph that contains a field may contain other things. If the hide-when applies to the paragraph only, then what about the other stuff. Surely there can't be two hide-whens, one for the field and one for the paragraph. What if they evaluate to contradictory hide states? And if it still applies to the whole paragraph, what about the case where there are two fields in the paragraph? Which field gets the honor of having @thisName apply to the paragraph's hide-when?

Point 1: Given the the complexities of manually optimizing for modern piplelined and multi-threaded chips, compounded by the fact that IBM supports many different client and server processor chips, it is highly unlikely that IBM's programmers could do a better job than the compilers that have intimate knowledge of each chip's capabilities built in.

Point 2: The performance of @DbLookup will mostly be determined by the performance of the Notes C API routines that it calls to do the database index lookups and all the NSF file i/o required for that. That code has been worked on by incredibly smart programmers for more than 20 years, and it seems highly unlikely that there are any significant performance gains to be made from code optimization. They have, on the other hand, gained performance from significant architectural updates to the ODS, caching algorithms, etc, over the years -- and those sort of things are where the achievable performance gains are likely to continue to come from.

Bob -- I'm totally mystified re how Eclipse could fit in on the server-side. There is an established API for hooking Notes API events on the Domino, known as the Extension Manager. IMHO, the way to go is to leverage that as a way to invoke Java cod, and extend it with additional events as needed. What value would inserting the Eclipse plugin model bring over and above that?

I voted to demote because your subject does not match what you are suggesting. The LotusScript language has not been enhanced in many years, and it was not the language chosen for xpages, yet it is a critical part of many core Notes features, partner applications and customer applications. Replacing it would require a rewrite of massive amounts of code. This isn't going to happen any time soon.

The choice is simple: either fix it and make it look and work like regular Notes mail; or just replace the Notes-based implementation with a basic Java IMAP mail client integrated into the Notes eclipse framework. And my assumption is that the latter will be easier for IBM to implement and support.

Further reason to demote: I don't believe for a minute that an open source project could manage the level of QA required to keep customer confidence. I.e., cross-platform and multi-version feature, performance and scalability testing, plus extensive regression testing and forward and backward compatability testing. This requires skilled and dedicated QA staff, and an envioronment with a large network of enterprise-scale servers running tests for all the different features of Domino, on many different versions of Domino, on all the supported OSes on all the supported platforms for the particular Domino versions, with all the different client platforms and versions, and with a variety of different localized versions for both client and server. Even running a statistically valid sampling of the above for a small but well-defined subset of Domino's functionality is a huge undertaking. I don't believe there could possibly be enough motivated volunteers with access to the necessary resources, the available time to do this job well, and the skills and discipline to get the job done adequately.

Even if there weren't the obstacles mentioned above, IMHO the principal reaction to such a move -- aided and abetted by Microsoft marketing, no doubt -- would be:

"OMG! IBM is abandoning Notes and Domino!"

The Law of Unintended Consequences strikes again.

This is a tough call. Losing a session slot or two is not really a good idea. Extending the session times and showcase ours out to 7:30 (or thereabouts) in order to make up for it, is going to be hard on a lot of people, too.

This is precisely what DXL could be so good at, if only it were fully-baked.

For further thoughts, see my response on Chris Linfoot's blog. { Link }

Why not just use a frameset with a page displaying above the form/view frame?

This is relatively easy to implement on your own through one (or more) queue database(s) where each doc identifies the job to run, the doc to run it on, the time, etc. The advantage of this approach is in the "etc." You get to decide what else needs to go in these job trigger docs. Somehow I doubt that any feature built into the amgr itself would ever get to the level of flexibility that we creative developer types will always end up needing. I designed a highly successful system around this concept, with a Trigger class that was invoked at startup of each agent to read the necessary information from the trigger doc, and then again at termination to update the trigger with info for whatever the next job in the workflow sequence will be. The disadvantage of this approach, of course, is that it probably can't be as efficient -- a master agent has to run through the docs in the queue every few minutes to launch whatever jobs are needed.

Hey?! Where'd my comment go? Harrumph. Have to type it again :-(

So, balancing both sides of what's been said here, my conclusion is that a compiler option is the wrong way to go about doing this. In general, I think it's perfectly reasonable to want to enforce non-use of extended syntax notation as a local coding standard, so I'm not agreeing with Ben on that but I do agree with him that there's the practical matter of all that existing sample code to deal with. Andre got it right when he mentioned Eclipse, because this should be an editor option rather than a compiler option, and it shouldn't merely disallow extended syntax. It should automatically convert extended syntax to the appropriate explicit method calls. That way, you can type code the way you're used to, and you can paste it in from any source, and your local coding standard can still be enforced.

Balancing all the points made here, my own conclusion is that a compiler option is not the right way to go about doing this. In general, I think that an optional way to enforce non-use of extended syntax as a local coding standard is a reasonable thing, so while I don't share Ben's fundamental objection in that respect, I do think that he's got a good point about all that sample code out there that could not be imported into any application where the option is turned on. Andre mentioned eclipse, and that's where I think the solution lies. It should be an editor option, not a compiler option, and rather than just prohibiting extended syntax it should automatically convert extended syntax into the equivalent explicit method calls. That way, you can type it the way you're used to, or paste it in from any sample, and still have your local standards enforced.

It can be done without DSAPI. You simply (well, that may be overstating it a bit ;-)) need to have application-level code make the calls to generate the LTPA cookie and then put the cookie into the response headers. Andrew Pollack has a product that does it. See here:

{ Link }

In general, code-signing is only secure when the signature verification is done by the component that actually loads the code file into memory. The JVM or the LotusScript interpreter in the Notes/Domino environment, both of which IBM controls and trusts, do this. But EXEs and DLLs are loaded by the OS.

Malware routinely hides or falsifies the identify of the .EXE or .DLL file that is running, so I see no reliable way for the Notes core code to validate an MD5 on the code file. I believe that trusting the OS to validate code signatures and vouch for them to authenticate with Notes/Domino would be an open invitation to major security holes.

Since forms are basically rich text fields that contain some extra controls, and since the majority (if not all) of the problems in round-tripping data notes come from failure to fully represent some of the more esoteric rich text features, I think solving the design note problem essentially requires also solving the data note problem. Nevertheless, I vote Yes on this in addition to voting Yes on the more general idea.

Ummm... What do you want this to do? Select a random element from the list? Put the list in random order?

Alan -- thanks for that link! I've wanted that capability forever. In fact, the first time I heard the product name Lotus "Notes" back in the R2/R3 days, I assumed it just must have a context-aware annotation/note-taking facility, and I was disappointed to find out that not only wasn't it there, but there was no reasonable way to build it.

Yes, Gavin, it is different from copy as table. Fields or columns would be ok, but ideally spanning several columns would be better. The clipboard supports multiple data representations. I think what I'd want is that if you select text that spans two columns and paste in a spreadsheet, it pastes it as columnar data in the sheet; if you paste it in a word processor (or a Notes RTF) it pastes as columns in a table, but if you it in Notepad (or a Notes text field) it pastes as a stream of text with just spaces where the column separators would be.

Yes, Bruce. In much the way you could do it over in the What's Hot list on this very page. In much the same way you could do it just about anywhere.

BTW: You can do it now on a column basis in views that are set up for in-view edit. I'd prefer that it not be on a column or field basis. I'd like to be able to be able to cut text that spans columns. But I'd settle for being able to do it on a column basis. And I definitely don't want it dependent on the view supporting in-view editing, as that feature (useful though it is in some cases) dramatically increases the probability of users mistakenly altering or deleting data.

Rob, that's excellent! I hope you'll let me know when it is available!

You can reach me at: rhsatrhs AT gmail.com

Interesting idea. But I would want an event handler bound to this element, so that custom code could decide what to do: abort the save, save with a default value, save with an automatically fixed value, save with a bad value but a flag set in another NotesItem (presumably to remove the document from normal views but make it available in an "errors" view), etc.

@2: It wouldn't cause confusion and incoherence if it threw a reasonable error dialog like: "Multiple databases match that replica id. Please select from the following choices.

Still, I don't think this is all that useful a feature.

An LSX isn't quite the point. The vendors that I know of who are doing things similar to what Plaxo would need are not using LotusScript. They are running an ActiveX plugin in the browser, using the COM classes or (in most cases I've worked with) going directly to the C API.

Yes, you are correct.. Notes 3 had categories.

The curmudgeon's answer: LotusScript is not C or Java, and for good reason. It is based on ANSI BASIC, and it should remain that way. Note that although VB.Net adopted many Java-like constructs in order to take advantage of features of the .NET CLR, it at least stayed faithful to its ANSI BASIC roots by not adopting ++ and --.

The practical answer: Furthermore, (a+++b) has legitimate semantics: (a) (binary-op-plus) (unary-op-plus) (unary-op-plus) (b), which would be read "a plus positive positive b" in today's LotusScript. Similarly, (a---b) has semantics equivalent to (a) (binary-op-minus) (unary-op-minus) (unary-op-minus) (b). If the pre and post increment/decrement operators were added to the language, these would become ambiguous. Would the meaning of the latter be "a postdecremented minus b", or "a minus predecremented b"? In the C-derived languages, the ambiguity is resolved by making the pre and post increment operators the highest precedence, above even the unary operators, which combines with the left to right rule to resolve the ambiguity. If LotusScript were to adopt this same precedence rule, then the semantics of the above legal expressions would change and existing programs would suddenly work differently. And some other legal expressions would become illegal expressions. E.g, in current LotusScript, the simple expressions (a++b) and (a--b), are both currently legal, but would become illegal if pre and post increment/decrement operators were allowed -- because it would become (a) (unary-op postincrement) (b), which is missing an expected binary-op before the "b". If LotusScript were to make the pre and post increment/decrement operators lower precedence than the unary operators, then semantics of the above legal expressions would not change, and existing programs would be fine (I think). But the semantics of LotusScript would be different from all other languages that have these operators, and that wouldn't be good either.

Now, I know that the situations I've described will occur very rarely in real code. And I suppose that an "Option increment" (or some such) to turn on the capability for these operators could be used to prevent any pre-existing code from breaking. But I'm still don't think I can promote this idea. I'll hold off on demoting for now.

Rather than a new field type, the idea that we should ask for is a way to program the range of years that the date picker allows!

This would require code-signing for EXEs and DLLs. Otherwise, it doesn't actually improve security. And given that there's no single code-signing system that goes across all platforms, I think it's not worth doing.

The better solution is leaving that option un-checked, and installing a custom EM DLL for each program that needs to share the password, such that each program and DLL are free to agree on their own mechanism for authenticating.

Bruce -- seems pretty straightforward to me. One more choice in the Idea Space drop-down, labeled "Other". For anything that doesn't fall into the previously defined spaces.

I think the Lotus User Group would probably be the right venue for this; but I have a feeling that many organizations would not want their info posted.

AND LotusScript isn't even needed. Simply searching for NotesDocumentCollection instead of DocumentCollection brings up the relevant help docs.

Aha! I see the source of confusion! I wrote it up wrong!

I wrote: "Starting from the middle and going up, the ten top segments are green for 10% promotes, 20% promotes, etc. Starting from the middle and going down, the bottom ten segments are green for 10% demotes, 20% demotes, etc."

I meant: "Starting from the middle and going up, the ten top segments are green for 10% promotes, 20% promotes, etc. Starting from the middle and going down, the bottom ten segments are RED for 10% demotes, 20% demotes, etc."

Which is what your latter example shows.

To be more specific, there are 20 segments in a vertical line. Let's say there have been 10 votes cast: 7 promote, 3 demote. Here's your stack of segments:

grey
grey
grey
greeen
greeen
greeen
greeen
greeen
greeen
greeen
red
red
red
grey
grey
grey
grey
grey
grey
grey

Aside fro security, I think the limits that would have to be placed on this (no @dblookups to other databases, and that's just the first thing I can think of) will make this too much of a maybe-it-works/maybe-it-doesn't proposition to really be useful.

@Kerr, Really wasn't thinking so much about abstentions -- but yes, what I described does do that, though I wouldn't say that they would jump out "at a glance". Anyhow, my primary motivation was to find a way to minimize the amount of color and the different shades of color used to convey the info. I really just envision it as a slim bar graph, showing positive and negative amounts collapsed into a single column.

@6 Nice aside. I'll have to remember that. I'm sure I can use it ;-)

But here's my answer. Yes, but you have a product! On the other hand, if you try to get 10 things that are 100%, most likely you don't have a product at all in the end! Or you do have a product, but you've missed your market window by so much that your 100% has now turned into 50%.

I'm afraid that it just becomes an arms race. Block users from creating toolbar code and they create button code in the rich text body of an email message! Block that, and they create a VB program or Java program -- or they download someone else's VB or Java program. Find a way to close that down, and someone's going to write Notes API code -- not a one-off thing, but a tool that allows users to write and execute their own programs against your data.

@6 re @3: I forgot to mention Activities, which bring together the pieces of ad hoc collaboration from disparate containers (including the Inbox!) into a virtual container shared by the participants. That would be a more effective solution for an organization with 25,000 participants.

@6 re @4: Easy maintenance of the reader lists can be programmed in some new entries on the action bar. (All I'm trying to get across here is that I believe you can solve this problem without requiring any changes to the core product.)

DXL fits all your criteria (source control, programmatic creation, opening designer to competition) except for using a text editor. Actually, it does that, too, but yeah... DXL wouldn't the easiest thing to read and edit by hand. But I don't that imagine a representation as a programming language would be fun to read and edit by hand either! And I think a "standard programming language" representation is far more likely to allow/encourage people to make edits that look like they should be perfectly legal in the language, yet can't possibly be executed by the Notes client or translated by the Domino server.

What's the matter with DXL for this? (Apart from the fact that it isn't guaranteed to maintain 100% fidelity on a round-trip?)

One last thing... even if you do get collaboration out of the mail file, it is possible to create the appearance that it is in the mail file. Code in the QueryDragDrop and QueryOpen events of a folder.

But... OTOH, I think you can probably do this without needing any new level of permissions in the ACL. Just combine Public Access rights and Readers fields. I.e., you grant Public Access rights to people you want to let in, and you put code in the PostDragDrop event of the folder(s) so that it sets both the Public Access flag and a Readers field on any documents that go into the folder.

This idea promotes the idea of using the mail file for collaboration, which means it is promoting using mail for collaboration. It's the opposite of the direction the industry has been moving for years, now -- except for Kubi Software, and they went out of business because they couldn't sell it. Get collaboration out of the mail file! Get it into a TeamRoom, or (better...) Quickr.

Love the idea. But I like my name for it, "Top Ten", better than "Favorites". The limit is essential to making this useful.

This also overlaps with Rob's idea, as he does mention a blog widget:

{ Link }

I see now that this is eerily similar to Rob's idea

{ Link }

Not by default, because it breaks existing usage that takes advantage of the feature.

But this is a good idea for an optional new checkbox property on computed text: "Convert to static text when forwarded, mailed or copied".

Submit that as a new idea, and I'll vote for it!

I like the idea of a visual representation of the ratio, but I wouldn't do it with background color. How about this:

A few pixels to the left of the box, there's a thin vertical line, the same height as the box. Actually, it's 20 segments stuck together. All segments grey means no votes cast. Starting from the middle and going up, the ten top segments are green for 10% promotes, 20% promotes, etc. Starting from the middle and going down, the bottom ten segments are green for 10% demotes, 20% demotes, etc.

I like the idea of differentiating ideas that you like from ideas that you really, really like.

But I don't like the dollars idea. I'm with Martin @8: "The beauty of the tool is it's simplicity".

I would prefer a simpler system based on what we've had in the BP forum for the past 10+ years: each registered user has 10 "Top 10" votes to give. I.e., after you click "Promote" you see a "Top 10" button, which you can click. The system prevents you from giving out more than ten Top 10 votes. In your profile, you can see a list of your Top 10s. You can click a "Withdraw Top 10" button on any of your Top 10 ideas to. The system will display Total, Promotes, Demotes, and Top 10s.

@2 - Your memory is correct. The application that puts data on the clipboard can (and many do) post it in multiple formats. The application that gets data off the clipboard gets a list of available formats and retrieves the one that it considers "best" for the destination.

The real point of "Block this sender" and equivalents in other mail programs is to give the user a feeling that they have _some_ power over spam, giving them something else they can do besides complain to the help desk! It's purely psychological.

SPF is not a spam filter. It is an anti-spoofing technology. I think IBM is more likely to implement DomainKeys, however.

Windows isn't going away soon, and every single new platform for Domino increases the QA and support matrix for IBM and for every single 3rd party vendor who supports a product that runs on Domino. There has to be a compelling market share story, or a truly compelling business strategy interest before IBM should port to any additional server platforms.

Not until Domino Designer is running in Eclipse.

Richard -- check out my blog post on that problem here:

{ Link }

And in particular, look at the 4th response, posted by Bernd Vollmer, which provides a solution to the problem.

As Chris says, this feature already exists.

@8: My actual request to Lotus (which spurred this idea) is for a warning, not actually to prevent duplicates. I'd like something in-your-face for admins, like a print to the console every time a duplicate is opened.

@7: I understand your point about the temporary need, and it's good that TSM sets restored databases so that they are disabled for replication, but that doesn't solve all the problems -- e.g., getDatabaseByUnid().

Unfortunately, I suspect that this exists due to demands from customer security officers. I guess I wouldn't object to it being hidden through policy, though,

I never had to wait at all. There was always already a cab waiting. I can't say that's true at all times, of course; just my experience.

Thinking about this some more, although I mentioned NotesPeek and that would be a cool UI, a DXL-based tool would probably be simpler to build. The poor-man's version of this would just be to dump the DXL from two NSFs, eliminate everything that is specific to a replica (e.g., noteids, etc) and then bring up the two files in a decent file diff program.

I like your last suggestion of a form property to only track changes in visible/editable fields.

The default is settable by administrators using policies. (Desktop Settings - Preferences - Replication - Encrypt Replicas)

You can stay at various lower-cost hotels, empty time-shares, etc., within a close enough radius that your total cab fare for round-trips for the duration of the conference will be about the same as the cost of your rental car.

We'd all like a discount, of course. But if IBM sells the number of tickets they want to sell, then by definition the price is right.

I voted to promote -- but I want to be clear about this: the feature should remain, but developers should be able to disable it with a single checkbox in database properties. The default behavior should not change.

All work on the workspace is time wasted. The effort should be put into making bookmarks work as well as the workspace for all purposes.

Not sure that I like the idea of a wiki for this. Too easy to post bad code, or mess up good code.