1 - Hi Bob,

congratulations on your new job! Glad to have a man like you in this job position.

To answer - somehow fuzzy - your question regarding the bigger problems, I guess the main obstacle is integration! Especially with other RDBMS. Personally I do a lot of integration to IBM System i (AS/400) and we sure need some native DB2 access back and forth! Besides that, integration in general!

My 'just come to mind' wish-list (I have added references to some of the above responses) while reading this blog thread:

1. Native System i integration
2. Sametime login through ST Client AND webbrowser at the same time
3. Sametime centrally logging
4. Server tasks based on Java (@33.2)
5. Hierarchy XML from "ReadViewEntries"
6. Views should show totals based on readers/authors fields
7. Drag'n'drop browser-component (Flash?)
8. File Upload to a "space" without saving the document first
9. File Upload progress information
10. Pre- and post- request/response to append content
11. Store document content in native XML field in DB2 Viper (needs System i support also!) (@37.2)
12. Retrieve values or sub-trees using XQuery from XML fields (@37.2)
13. @Authors should return authors from ALL authors field
14. @IsAuthor in computed text fields and views (true/false)
15. Get rid of the 32/64 Kb limits on strings (@33.5, @51)
16. Get rid of the 32/64 Kb limits in source sections (@51)
17. Add license code support
18. Make it possible to "hide" @formula code like you can with LotusScript
19. Allow file uploads controls in template forms
20. Better and faster Servlets/JSP support (@33.1)
21. Custom JVM support (version/vendor)
22. Digital Signatures support (fx. OCES)
23. No limits in summary data
24. MD5 etc. support in @Formula, LotusScript, Java
25. Plugins (@36)
26. Remove @-char in front of JSON output names
27. Save or replication conflick resolution with automatic populating response or related documents
28. Better Internationalization/Multilingual support (@51)
29. JVM R6 support (@52)
30. @ReplaceSubstring on RichText content (remove Kb limit!)

And then of course I second a lot of the suggested improvements other people have suggested above.

Please feel free to email me if you need further clarification on any of these items

2 - @11 - I had a few mails with Bob, and his last reply was "I agree, HTTP functionality in LS would be a nice enhancement.", if I may citate him :)

Basically it would not be called AJAX anymore, but core LotusScript HTTP functionality. I think it might step on some business men's feet as it's way too powerful for today's economy, since you could connect to any Mainframe, ERP, or other system, or internet site which works over HTML (and URL parameters (but also cookies will work)) from Domino without having to configure or program anything on the other side.

For example my guild's web site (a Domino 8 based site/forum), uses direct HTTP (now using the buggy Microsoft XML 6.0) calls to World of Warcraft items, which are also buffered into a Domino database for faster re-access. The same idea would work for any internet site.

You can try it at { Link } and make a post for example with [wowitem]Azuresong Mageblade[/wowitem], but don't spam it too much please :P

3 - If we are talking pie in the sky types of capabilities here is my list:

1) An extension to the NotesSession object that allows for the registration and pooling of external RDBMS connections for use from any script (think a collection of global LCLSX LCConnection objects that are instantiated under the NotesSession object.)

2) Full CSS2 support for all design elements that render inside of the Notes client properly and that completely honor any uidoc.refresh

3) An extension to the <computed text> that allows the programmatic assignment of text style attributes (even if only the assignment of a CSS ID/Class...see #2)

4) Completion of various design element strategies: remote embedded views parent db computations, DXL for ALL design elements and attributes, etc

5) A 'layer' design element that exists outside of the form that could be shared amongst forms/subforms or the ability to 'layer' subforms directly (akin to 'shared' CSS <div>s in the client?)

6) In addition to #5 and as part of #2, the programmatic control of layers and their positioning that honor uidoc refreshes

For items 2-6 I guess what I want is programmatic control of the form similar to what I have via CSS2 and javascript in the client, exactly like I have with CSS2 and javascript as a matter of fact, just with CSS2 and LS or formula language; and oh, I want it to render properly and honor refreshes

4 - @21 "Does basing Notes on Eclipse in Notes 8 get us any of this?"

The R8 client is Eclipse RCP with Expeditor on top. The RCP doesn't include all the dev tool stuff from the Eclipse PDE. Hopefully, the forthcoming (post R8) Eclipse-based designer will use the full Eclipse PDE so the resource model, advanced editing capabilities and plug-ins will give us all the "standard" IDE features and third-party extensions. It would be nice to work in ANY jvm-hosted language(jython, jruby, groovy...). Every time I suggest hosting Lotusscript on the jvm, people go ballistic. It would have everything @22 asked for and more including threaded network IO from http down to sockets. VB.NET does all this on the CLR. Workplace designer uses jvm-hosted javascript. IBM didn't even use rhino for that, they rolled their own.

@22 I agree that the biggest challenge will be to add power while still allowing the high velocity development that we're used to. While Bob will be advocating for kick-ass dev features, marketing may be advocating a gentle slope for current Lotusscript developers. I have concerns about this.

I think we're being a little too focused on the tools. Bob's mandate is programmability. What capabilities will these tools targeting? What is exposed in APIs and how? More to think about. As for tools, extensibility is numero uno. I would hate to see a Domino designer that was not as extensible as eclipse itself. Extension points rock. More is better. Let us help with the tools Bob!

5 - Bob, thanks for answering! (@44).

To elaborate: Yes, LS:DO *exists* for AIX and Solaris (though not Linux), but it might as well not for most purposes. It expects that there will be a DSN registry on the machine that it's running on. This never happens, realistically. (Would you install the ODBC platform on your *ix box if you were an admin?) The only place in which this external library works is in an all-W32 environment, where I should just use the ADO active-x object anyway. Also, it doesn't allow connection data to be entered using only "Connection Strings" in the code. There *has* to be a DSN.

LSXLC is a little better in that regard, but it sorely needs updated drivers (MySQL, Oracle > v8, etc.), and there's no easy way to add them. I'm not even sure that there's a difficult way to add them.

Basically, there has always been some kind of barrier to using LS:DO and/or LSXLC. What would make this work in every programming environment is:
1. All the basic plumbing should work out of the box, on every supported (server) platform, without having to install (or import) anything else.
2. For anything that can't, by nature, come out of the box (e.g. A DB driver for an RDBMS that hasn't been invented yet), there should be a way to plug the missing part right into the NSF, rather than having to do a server install.

Bits and pieces of this are in place, but it's never been really completed properly. Everything else in Domino kind of just flows, by comparison.

For a conrete sort of example, we should be able to simply write a server agent kind of like:
Dim s As New NotesSession
Dim con As RDBMSConnection
Set con = s.CreateRDBMSConnection( "MySQL", "{ mysql connection string goes here }" )
Call con.Open()
...

I hope this makes what I'm envisioning a little clearer. I wouldn't be asking for it if not for the fact that I've run into so many problems with the current state of things. I've even had admins who have deleted the LS:DO library file from the server in the name of "security".

As to the language-of-choice issue, you should really look at what Simon Brown (@31) did on his site. He basically used BSF as the interpreter you describe, and the bonus of BSF is that it exposes the entire range of loaded Java classes to the interpreted language. This makes the product objects instantly available. All we'd need is a way to type the code for our favorite language directly into a design element, and we'd be in good shape. Although, Simon reports that the speed could use a boost, this is very do-able in practice.

Thanks for listening!

6 - This does sound like great news.
It isn't exactly programmability, but while we are discussing AJAX, I've been playing with the domyui project from OpenNTF this afternoon. I'd love to see something along those lines as a core piece of Domino, so that we can deploy "Web 2.0" apps right out of the box as the default implementation of a Notes DB in a browser.

In any case, good luck in the new role, and I'm sure the whole community looks forward to seeing what the future holds.

7 - @22, you only need to create methods/attributes for the ones you plan to access. If you plan to access many, you always have the option of making "wrapped" class object public. Yes, that defeats the notion of data hiding, but it works today.

There's an example in this article:

{ Link }

The reason I'm bringing up Delphi here is that it's the only other RAD tool I've used that I'd call kick-ass. Once you knew what you were doing*, you could build, for example, a Notepad clone (complete with File | Save) in about half an hour (or less). Delphi excelled in areas where Notes does not, like building sharp UIs. Notes apps have been criticized for looking and acting "different". Better tools for UI development would address that problem.

*which didn't really take very long

8 - Congratulations!

If I may expand a little on @35:

Right now, there are a lot of hoops to jump through in a large IT organization if you want to do any serious RDBMS integration in a complex ND application. What I would like to see is a LS Product Object that works exactly like MS' ADO (or alternately, much like JDBC), that is compiled for every platform (thus, no need to worry about whether the code will run on W32 local vs *ix server), and can speak to DB2, Oracle, Sybase, MySQL, and MS SQL Server out of the box, with nothing added, and no need to import an LSX.

While I'm rambling...

* I'd like to see some incremental improvements in LS, perhaps adopting the improvements that went into VB.Net, or even just baking in support for static members and functions as first-class objects (which I know is much easier said than done).

* I throw in my vote as well for more scripting language options, which all have access to the Product Objects, and are usable *anywhere* that you can write LS. (My preference is Ruby, but everyone has their own favorite language, so you might as well see what it takes to cover as many as you can.) For that matter, Java should also be usable anywhere that you can write LS, although LS2J can help get around that presently.

* Another agreement: We need DXL representation for anything and everything that can appear in an NSF, and we need it yesterday. Also, the DXL engine should really stop putting in those random line breaks at around 80 characters.

* Lastly, I also throw in my vote for better html rendering. Ideally, there should be an *easy* way to get under the hood of the rendering engine, such as providing every granular object on a page/form/view (i.e. Paragraphs, fields, view rows, actions, etc.) with a "Render event" that can be computed via formula or your favorite scripting language into valid (or not, if we're not careful and testing well) HTML snippets. This way, you can satisfy everyone, no matter how they want their HTML to come out, and still provide a baseline default for everything.

9 - Ok, it's late and I finally caught up with all your great posts on this thread. So, I'm going to post my replies and comments in one big "Postzilla".

Let the conversation continue!!

@25 - Thanks for the compliments, Axel!
Regarding using open source code in our products -- I certainly understand the utility and the
desire to do that, but unfortunately the legalities can make it very difficult to accomplish.
For reasons having to do with intellectual property rights and ownership of the non-open source
parts of the product, we have to be very careful and get all kinds of approvals to incorporate
outside code. That does not mean it can't happen (we've done it before), but it's a complicated
process.

@25/@26 - There are lots of relatively new (newer than Ls/Java, anyway) languages that come up
all the time on someone's wishlist. Obviously we can't provide implementations of all of them,
nor do I think that would be a good idea (my goal is to simplify, not complexify when possible).

But tell me what you think of this idea -- What If we had a plug-in mechanism (based on Java patterns)
that let you execute your own code using your interpreter of choice? Think of it as (maybe)
Extension Manager based on the jvm, with a simpler event hook/listener type implementation. Your
event handler code could (if you choose) invoke some other program. Of course there would be
advantages to sticking with Java, like access to the Notes objects. Maybe you would store your code
in some version of a Scriptlib.

Just brainstorming at this point....


@29 - Right! Sometimes the distance between a hack and architecture is pretty small!


@33 - Wow, good questions! Too early to say anything for sure (and I'd get fired for
"announcing" stuff here anyway...). I assume your reference to "features that were withdrawn..." from
R6.0 means that thing called "Garnet"? It's ok to mention the name again, I checked

I wasn't an IBM employee when the Garnet capabilities were put in the R6 beta, but I sure did
like it a lot. I built demos, gave presentations on it, and wrote articles about it. When it
was cancelled I was saddened, as were many people.

I am finding, now that we (IBM) are beginning discussions internally (and externally, like this one)
about how to make the platform better, that Garnet is being mentioned surprisingly often in the
hallways and conference rooms.

Obviously I can't make any promises, or even solid proposals at this stage of the game (I've only
had my new job for 2 weeks, and I haven't had time even to order new business cards...).

To address your question directly, "will we see domino back as a first class web application platform,
where it should be?" The answer is a very strong "I hope so!", but I don't really know what
that would look like yet, or when you'll get it. It is definitely on my list of goals to accomplish.

To your other question, "Or are you only going to be looking at Domino as a platform for the Rich Client?"
The answer is: "I am definitely looking at ALL types of clients, browser (implying Web apps), rich client
(Notes apps) and, well....others too. That's not a promise that we can do everything at once, of
course. ANd it's still too soon for me to talk about things that are still the subject of intensive
research and debate internally.

But stay tuned!

Re: Large text fields. I (when I was Looseleaf Software) actually implemented that in an LSX. Gives you
stream interface to up to 2gb of text storage in a document, replicates, everything. Pity nobody bought it.


@35 - Regarding your suggestion about "global" dbms connections, LCLSX already does that, in a way.
If you turn on connection pooling you effectively get that, it re-uses previously established
connections.

@39 - Regarding your wish for a non-LSX JDBC, well, we have that, and have had it since R4.
It's called LS:DO (LotusScript:DataObject), and it is essentially a wrapper around ODBC, so you
get access to all the common DMBSs. Unfortunately the object model was a bit awkward, and not
many people use it today.

The LCLSX capabilities are still there, however, and pretty straightforward to use (I recently
used them quite a bit to implement Notes access for SAP solutions). I don't understand your
objection to loading an LSX (especially one that comes in the box with the product). Can you
elaborate?

10 - There are some great suggestions here. One thing I haven't seen mentioned is improved printing support. Think about natively printing to PDF...even generating combined documents in PDF on the fly for reporting.

11 - Congratulations to Bob on the new job and thank you for canvasing the community for ideas.

I have a list of little annoyances aka "I wish notes did that". Is it Christmas already? First though, I want to clarify something. What type of apps are we talking about? Are we talking about the ones that Notes has been designed for, all those long years ago, such as knowledge sharing, collaboration, messaging, etc? Or are we also talking about apps that have since found it's way into the platform such as web sites and web apps, and domino as a middleware platform for integrating different data sources?

At the risk of stating the obvious:
Ultimately, any framework has it's strengths which flow out of the design decisions that have shaped it. Consequently it will solve a specific set of problems (very) well, while other problems will either be difficult or altogether prohibitively complex. So when we find that Notes does not do something that we want is it because we are applying it in ways that it was not intended for in the first place? Granted the line gets blurred when customers demand a solution and for one reason or another Notes is the implementation technology.

Again, at the risk of stating the obvious...
In my opinion Notes has been a kick ass app dev platform back in the day because it has focused on a problem space and created a solution space that addressed it very well with much less programmer effort than other tools of the day. Now it seems that the problem space has increased. And it's no wonder since we are all trying to solve bigger and more complex problems.

So what are those problems? What categories do they fall into? How are they related to Notes traditional strengths? What new directions are we pushing the product in?

In that light I would like Notes to address new problem domains with the same easy of programmability as the original apps back in the day, when we could do it all with formula language and wow a client turning around a functioning prototype in a day. Some of the new problems that I want to solve are the ability to work with complex data sets, beyond lists and collections. I also want to be able to have a dynamic UI that is or can be decoupled from the data store.

What I am saying is that I want all the support from the framework and at the same time I want to be able to go outside of that framework at no or at minimal cost and without breaking the framework. Does it sound like the holly grail of programming? I suppose so, but that's where it's at for me. Otherwise, we stick to solving the small set of problems that notes has been designed for but do it well, no do it much better than now and on more platforms (web, desktop, mobile, etc).

That would be my $0.02 worth of a rant ...

12 - Here are a couple of my wishes, some are based on earlier responses above:

* Autocomplete in any field. New property in the infobox, should work like "Use formula for choices". Fixed list of values or @formula to define the list of items in type-ahead.

* I agree with Hynek (item 5 about alias). I would also like to see the alias being accessable in the UI classes. When you open a document and use uidoc.FieldGetText("MyField"), you get the visible value, not the alias if it exists. So if the value is "Foo" with the alias "1", you get "Foo", not "1". The idea with an alias is that you should be able to change the visible values without having to worry about changing any code...
Suggestion: uidoc.FieldGetValue("MyField", True) to get alias... Or if this is too hard to do (due to backwards compatibility), uidoc.FieldGetValueAlias("MyField") or something like that...

* I agree with Simon (#31) about the HTML output. Much more control of teh HTML output, in all design elements.

* An updated/modernized editor would be nice, but I would not like to see too many drastic changes. But it would be rellay nice to be able to build "components" in LS that can be shared between applications and users, similar to OCX in VB... Imagine what the Notes community would do if we got something like that, you build stand alone functionality/UI components that can be plugged in by anyone... Perhaps someone builds a kick-ass calendar control, it can be wrapped into a component and shared.

* Computed column titles are good. I think that could be very useful. What about other view improvements? Multi-line views with different columns on different lines? I will try to explain by using an example.
I want to be able to create a 2 line row. On the first line, I want to display the following columns: Lastname, Firstname, Department.
On the second line, I want to display City, Phone, Email.
I want the two lines to count as one, so I can use alternating row colors. But I would alos like to be able to set individual text and background colors (perhaps even a background image) for each column/"cell". So Lastname could have a green background while City could be yellow, despite being in the same "column".
Of course, you need to keep the current (programatic) color columns, but it would be nice to be able to set colors in the column infobox.

13 - Hi,

here is my wish list for changes in Domino Designer 9.0 : { Link }
The most important are item 4 (Computed column titles) and item 6 (Display a dynamical subset of data from a view).

Thanks for asking and great news for us.

14 - This just gets better and better!

Yeah! Go for it!

---* Bill

15 - Bob, can I beg, plead, and otherwise cajole you into emailing me so I can get you a very early version of a very deep idea that I have that will be RIGHT UP YOUR ALLEY? nathan.freeman@lotus911.com

I don't want to blog about it because I don't know whether it's even remotely feasible, and I'm trying to muster up some private level of support before I put it out in the world.

Thanks. Hope I hear from you!

16 - Hi Bob,

it would be great if we could make Class-diagrams & Sequence diagrams from LotusScript classes for documentation

17 - @8 - I'm trying to figure out how Asynchronous JavaScript and XML fits into Lotuscript. It's not coming to me.

I suspect you simply mean that you'd like Lotuscript to have the ability to asynchronously access HTTP resources with reasonable ease. And there's some ability to do this coming in Notes 8, since you can have a script library consume a WSDL definition and present it as a script class. Unfortunately, I haven't been able to dig up any documentation on how this works yet. And experimentation has gotten me nowhere, since Domino Designer seems to expect some fairly specific formatting of the WSDL definition.

If it's anything else, the question doesn't really make sense. How would you want Lotuscript to provide native support for Javascript? We already have enough troubles with LS2J! :)

A thought for making the implementation ridiculously easy... what if the NotesStream class had a .openURL method? The key thing would be that it needs automatic support for HTTPS and some type of cookie maintenance so you could do persistent authentication. But that would be the easiest way in the world to do the overall job, because then you could pipeline into a DOMParser just like 1000 other apps already do.

18 - Dear Bob!

For christmas I would like to have a session object where I could store information about the user using my website. The object should be accessible to put and retrieve data from @Formula, LotusScript and Java.

Kind regards
Tomas Nielsen - Domino fan

19 - @5 - Come on Rich, you have my email, send 'em over!
@6 - Hey Bruce, thanks for the suggestions. As you know, IBM is usually more about middleware and integration than about packaged point solutions (that's not to say we never do that, just mostly not). So you can bet that ease of integration is high on my list
@8 - Mika, can you say more about how you would want such a thing to work? Feel free to reply by email.

Thanks to everyone who's commented so far. Keep 'em coming!

20 - Hi Bob,

I'm a bit late getting here, but this is *GREAT* news Bob! If you're asking for "big picture" problems, then here's my input:

- International application support. Formulaic view titles would be a "small effort, large impact" piece here.

- Web integration. Better HTML rendering, formulaic HTML tags, consuming HTML (probably addressed in ND8), etc.

- NSF limitations. 16K limits, 32K limits, etc.

- DXL. Round-trips of anything. Yes, rich-text conversion is a mess and could takes years to achieve 100% fidelity... but there shouldn't be ANY excuse for not having access to every piece of every design element's properties.

21 - @15 - For asynchronous HTTP functionality in LotusScript you would need concurrency in this programming language, which would be great in it self.

What I really want, is more "object orientation" in LotusScript:
- What about real polymorphism (same method name, but different parameter signature)?
- static methods (methods of the class itself instead of its objects) and attributes.
- interfaces
- operator polymorphism (define a new + operation for own classes)
- subclassing of Notes' built-in objects (I know, there are implemented in C++, but why should subclasses not possbile?)
- etc.


For the IDE my wishes are:
- class browser (show a outline of classes with direct links to their methods and attributes)
- code completion for my own classes and functions


and
- "perfect" DXL round trips (export and import)
- better CSS support: every generated element should be "accessible" (like action bar)
- HTTP task should generate better HTML (standards, xhtml, css)


These are my wishes for the moment, since it is about 3 am now.

22 - Excellent news, Bob! Let's talk sometime soon. Lots of ideas I'd like to share with you. Lots.

23 - Hi Bob,

i just wanted to add an other item that i have forgotten:

- Run agent/code on the client with other persons execution rights

Sometimes we need to run some code which performs an action which the user is not allowed by its ACL. Todays only solution is to trigger an agent with .RunOnServer. This is not really convenient as parameters can only be passed through a "saved document" and no messageboxes can be displayed to the user. (Ah and it does not work while offline.) It would be great to get a feature like "Run with agent signer access rights" for an agent even when triggered locally.

(I know that this may be a security risk, so it has to be evaluated greatly.)

24 - Excellent news for Bob, for IBM, for us...

25 - this is very exciting news. Really pleased about this and I have lots of ideas, mostly documented in the partner forum. Top of my list at the moment is stateful web services and a javascript consumer library.

26 - Great news for you and us all!.

Top of my list on the IDE side is to bring my Dev experience into Eclipse (not RAD) and let me do all my nsf dev there.

On the notes client side, I'd like to see a heap of source come out of Notes 8 for things like the feed reader, conversations, recent contacts, autocomplete address fields. That's how we learn. That's what we did with IBM .ntfs in the past.

On the server side, it would be nice to have a LS and Java access to the request/response before and after the context of page x being served. In ASP.NET, they call this the 'pipeline' and you implement httpmodules and they are called during the request processing. It allows you to do things like filter urls and responses at the server level (not at the nsf or .html file level). In Domino, right now you have to go DSAPI to do that and it's not productive unless you code in C every day.

27 - I'd second the call for an out of the box source control system. TeamStudio do a good job with CIAO but even so using the product is still considered a PITA by the developers I work with.

A class browser would be nice, but I'm guessing that if the Designer is ported across to Eclipse that this would be more difficult not to provide!

I know this is not going to be especially popular but a way of documenting a Notes / Domino application a la JavaDoc would be greatly appreciated and placate those pesky auditors!

And finally (for now at least), a formula debugger, anyone who's done any serious development with Notes or Domino would chop off a leg to be able to properly understand why (or even where) a formula is failing without taking the whole form apart.

Hope this helps.

Matt

28 - Hey, I used to work for Lotus sometime back.

I'm curious to know when it lost the "kick-ass development platform" title?

29 - It'd be nice to have some built-in LotusScript classes to create/edit/remove Connection Documents, Location Documents, Contacts, Calendar entries... more? The classes could look at the user's mailbox design, or nab design, and create the proper version.

Dim cal as new NotesCalendarEntry( type, dateRange[] )
cal.SetDetails( notesRichTextItem )
cal.SetParticipants( ... )
cal.Save( ... )
cal.SendInvitations( ... )

Or, point the cal object to an ICS file, or URL.

Yes, I realize we can do this today with custom classes.

30 - Hi Bob and everyone,

My wish is :-give notes designer : refactoring, code-completion of custom classes, custom shortcut keys

-improve java : give UI classes to java and possibility to code UI events in Java in a form. Make us up to date: lets have jre6 support.
Lets have LotusNotes java annotation : for exemple the possibility to add role based security on a java method @role = "admin" or the possibility to start a transaction @transaction...

-Lotusscript should support ObjectOriented main features

-dxl : simplify the api to get dxl of a design element

-export a form in xform ???

-Web development : make an ajax dispatcher allowing to call a method in a script lib from the browser with ajax and returning the result in xml or json : its basically an agent that gets scriptlibname, methodname and paramterlist from a xmlhttprequest and call the method and returns result to the browser.

Add the possibility to customize the output format of a view in xml

Make http engine render a date field has a calendar pickup.

Give us a cool new langage : ruby maybe? javascript is introduced has a serverside langage in lotus component designer, could be javascript has a serverside language on domino?

31 - Much of what's talked about here, in terms of http support, class Inheritance/Extension/Static methods, etc., etc.- is all done in Java. I know I know, *we* want that stuff in LS too. But it's there now. The problem with that is the IDE for doing any Java work is limited to the backend (no UI support) and the Dom. Designer Java development and debugging is pretty bad- it's painful. I do like all the suggestions for code completion, intellisense type functionality for one's own custom classes.

Make java development easier for Domino developers.

32 - @17, you can extend Notes classes by composition (wrapping a Notes object with another class). Not perhaps quite as nice as inheritance, but it works.

Right after I posted my original wishes, I saw Nathan's blog post advocating that we think big (bigger than class browsers). Here's I'd really like.

How about a Notes IDE that's more like Borland Delphi? It would have many more kinds of UI controls (and pixel-precise layout for them), a better event model, and the ability to seamlessly integrate third-party UI controls (if they're built to spec). And of course Notes would continue to handle security, email, workflow etc just like it does now.

Yes, that's asking for a lot, but it would be seriously kick-ass. Right now, Notes apps tend to have a somewhat primitive look and feel. It takes a fair amount of work (and skill) to get around that. Making it easier to build modern-looking/acting apps in Notes would help address the perception that Notes is "old technology".

BTW, Does basing Notes on Eclipse in Notes 8 get us any of this?

33 - @21 & @22 - Andre Guirard mentioned in his podcast that there will be indeed an Eclipse based Domino Designer in R8.5 or RNext.

34 - @45 & @46 - Noted! Will research further. Thanks!

35 - @14 - I learned that AJAX is the wrong term, what I wanted was core server based LotusScript HTTP functionality. Synchronous would be easier to implement as that's how the Msxml2.Microsoft.XMLHTTP.6.0 works already today, just that it's not cross platform.

The first challenge would be to make the synchronous HTTP functionality in LS work on all platforms, as you know LS runs on a number of platforms so there's quite a lot of work involved.

The second challenge would be to make it work asynchronously, and I don't know if W3C has finished their standards yet:
{ Link }

Since server based LS agent just run and finish in a few milliseconds, the asynchronicity would have to be manager somehow via documents, like agent parameter documents (or something else if you have a better idea). Or then server based LS agents would need also a new functionality to stay alive while waiting for a request, or always be alive and utilize the OS sleep() function to free CPU resources while waiting for the responses from the HTTP stream.

Yeah well, it looked so simple, but it ended up in being another world wonder, if fully implemented.

But even the synchronous HTTP functionality would be a vast improvement. Which should be a relatively realistic starting point.

36 - @17 & @21 -- The LSX Toolkit allows you to extend the Domino classes - check out the LSXBEPlus (hence the name) sample (\lsx\src\LSXBEPlus) and its test file \lsx\tests\LSXBEPlus.lss.

It just works. When I told Bob I got it working, I called it a 'hack' - he said "that's not a 'hack' that's 'architecture' ".

37 - @10, I'll do that. But I still want to chat

And a question: do your Programming Services Architect responsibillities cross over from Notes/Domino into other product areas, like Activities and Connections??

38 - 1. Don't turn the dev environment into Java - I can keep pretty much all of Notes language in my head so I can get from concept to implementation without spending hours poking around for a method that works. (I think you said something about not going too complex so you seem to have this on locked!)

2. Some LS/@Function hooks into some of the deeper API stuff - specifically, I would LOVE to be able to play with the user login bits - detect login failures and be able to respond without writing C/C++ code (it'd make Part 11 compliance easier).

3. Programmer default setup - Really, I do NOT want the #$%% property box popping up every time I open a view in design mode, let me turn some of this stuff on or off.

4. Programmatic access to any field label (view colums/tab names for instance).

5. Better integration (maybe just better documentation) with other IBM products - figuring out how to make LCLSX work with Oracle has been a total PITA. It works like a charm, but what an ugly learning curve. Same thing with Db2.

6. Screen lock command. Waaaay back in Lotus Symphony, I had an option to tell Symphony to freeze the screen while I did a bunch of UI stuff and then unlock the screen when I was done. If I write code that automatically flogs the UI, it'd be great to just make the screen sit still until I was done. With faster PCs and the option to use LS on the backend, it's not a huge issue, but it'd still be nice.

7. More flexible launch options - let me cranck a db up with any design element of my choice, doc, view, frameset, outline, page, whatever. Currently (R6.5x), I need to stuff things into things into other things into framesets to get the page I want fired up on db launch (and I'm probably doing it all wrong but it's not clear to me how to make it work any other way).

8. Keep it up. Notes is dead (again), Long live Notes! Congrats and thanks for asking.

39 - First of all, thanks to EVERYONE who took the time to post comments and suggestions here.
This is great stuff, and while I can't reply individually to each one of you, I do
appreciate your input.

Thanks also to those of you who have emailed me. Again, I may
not have the bandwidth currently to reply individually, but I am certainly reading everything I get,
and recording for future reference.

I do want to clarify a couple of things for you all:

1) Regarding tools -- not really my area of focus, though it's a fascinating discussion.
My charter is on the platform (client and server). Naturally, I expect to
(and already am) talking to the tools teams quite a bit.

2) Individual feature suggestions are certainly relevant and welcome, but I'm really not ready
to address things at that level yet. My first set of goals has more to do with solving
some of the big problems we (the development and product management teams) think
we have.

3) So, now you probably want to know what I think those problems are, right? Well, I'm still
collecting input on that topic, and I'm not ready to share yet. But I do want
YOUR input. What do YOU think the "big" problems are?

Having said all that, you all should also know that it's almost time to take this discussion out
of Rocky's blog and move it somewhere else. While it's true that Rocky likes what this thread is
doing to his traffic numbers, he has also been nagging me (for years!) to start my own blog. It
looks like I'm finally going to cave and do that. It's still being set up, but I'll announce it
on LotusGeek.com ASAP.

40 - Bob ! Bob ! Bob !
GREAAaaaaaaaaaaaaaat news ! (readying my feature request list eheheh)

41 - Two things I didn't see in any of the above suggestions.

1. Add JavaScript versions of the web based Java applets. Publish the code and let the developer change them on a db by db basis.

2. Give us a web based JavaScript rich text editor. (Did I say that in #1 above?)

42 - Hi Bob,

I'd think in these discussions it's useful to think about the platform capabilities and the development tooling separately. From your post it wasn't clear where you will be focusing; platform capabilities, tooling or equally between the two?

By tooling I mean Domino Designer, debugging, code completion, source control, etc. Hopefully these features will come with Domino Designer being surfaced as eclipse plug-ins.

By platform capabilities I mean services provided by the core platform. Imagine we had full resolution of a notes DB in DXL, I could write it with a text editor (shudder) and access all the features of the platform. Additionally there are APIs for the core server that I can call externally.

Historically, one of Domino's strengths was that the application was all self contained in the nsf. As a developer I could design and build the application, maybe using more than one db and send it off to production. As long as it got signed and configured correctly it'd be fine, few external dependencies.

The release of ND6 saw Domino being positioned as a second class web application platform. Features from the beta that would have provided a step forward were withdrawn in favour of bundling WebSphere. This consigned web development on Domino to the doldrums or forced developers to deal with two separate platforms. Integrating WebSphere with domino is clunky in the extreme and if you are building a web app it is often be easier to just abandon Domino and go with a WebSphere on RDBMS solution. Looking back to those days, maybe that was the plan.

Are we going to see a change in that position? In this brave new world of ND8 will we see domino back as a first class web application platform, where it should be? Or are you only going to be looking at Domino as a platform for the Rich Client? Don't get me wrong, I wasn't Domino to be a storming platform for Rich Client development, I just also want to see it be a storming platform for web development too.

I also don't have a problem with WebSphere, I use it extensively. If solutions involve using the guts of WebSphere I have no problem with that. We just need to make sure that it's done tightly. Ideally this would involve nothing more complicated than typing "Load WebSphere" at the domino console.

So with all that said, here are a few things I'd like to see added to the platform capabilities. I'll leave a wish list for tooling for a later date; there have been many good suggestions so far.

1. Long Running Java Processes.
Similar to a Servlet engine (could be a Servlet engine), allows Java code from a database to be loaded once and then called many times. Could appear like an Agent but with the addition of scope option for "per request", "per user session" or "global"

2. Java Add-Ins.
You can have Java Add-Ins at the moment but they are not supported and probably are not as fully featured as they could be. Especially useful if you have...

3. Low level Java API.
Similar to the C/C++ APIs, access to the basic building blocks of Domino from Java code.

4. Support for JVM based Scripting Languages
Mentioned before. Groovy and JRuby are of course the big hitters. Sun has also done some work on VB compiling for the JVM with a project called Semplice. Does anyone want LotusScript running in a JVM? (Also Simes above is obviously not blowing has own trumpet enough, check out his blog for an experiment in shoehorning JRuby into Notes. The boy's mad. A genius, but mad. )

5. Large Text Fields.
From a user and developer point of view these would behave exactly like a non-summary text field, but would be able to hold any about text (or same as rich-text, up to 1GB limited by disk space) . Looking at the guts this could be chapped up over many items, but when designing a form or accessing the item from the LS / Java APIs it would behave like a single large field. Note, this should always give you what you put in. No paragraph or line breaks should be introduced in any output from these fields.

6. @functions for handling XML.
@XMLValidate(), @XMLXPath(), @XMLTransform() I'm sure we can come up with more.

7. @functions for handling character sets.
Convert to/from characters / hex codepoints for given charsets. Similar to @URLEncode() @URLDecode(), but for any named charset e.g. @CharsetEncode("UTF-8"; "Quick Brown Fox"), @CharsetDecode("UTF-8"; "517569636B2042726F776E20466F78");

Ok, that'll do for now. More to come I'm sure.

43 - The other thing is that with Java 6, there is inbuilt support for scripting languages with the inclusion of JSR223, so there wouldn't even be a need to include BSF.

44 - FanTAStic news!

45 - It's good to hear this is a priority for someone. It was making me crazy hearing server release/client release over the years, but never developer release.

An integral Source Control system and class browser would be two of my top choices.

Yes, I realize I can buy these elsewhere, but why should I have to? A kick-ass appdev platform would have these things - or a least a seamless way to integrate outside tools.

46 - And here is the votes from me.

* Eclipse Edit IDE for Sources
* Support for Java server tasks
* Support for user session objects with http
* @week it exists in LS why not in @formula
* More options on how and when converting richtext between mime and Notes richtext format.

* Programming control over the openoffice components in Notes 8

* Programming control over Domino 8 open office components if using domino thru an webbrowser. (light client if users want to use them thru web), to meet up with sharepoint portal server

47 - 1. Better Java support.
By which I mean, Java should not be shoehorned into the Script Library model in the way it is now. Or at least, if it's going to stay the way it is now, let me use JAR files as "script libraries" directly.

2. Script languages as first-class citizens.
Once the JVM moves up to 1.6 the support for JSR223 will be there, and that allows the potential of writing agents in any 223-supported language. It would be possible to hack something up using Java agents to kick off the scripts, and I've been looking at doing that with BSF, but it would be really nice if it was built-in and we didn't have to build all that scaffold ourselves.

3. Domino still creates terrible HTML. There are tools out there that let us create great web UIs - Domino should be one of them. Right now a great web UI on a Domino app occurs in spite of the tool, not because of it.

4. Second Matt's call for a formula debugger. This has been overdue since there was formula. :)

5. Relatedly, unit testing support for design elements. There are no easy hooks into forms to enable automated testing of them, and there should be. This combined with the lack of debugger makes form development a deep black hole into which huge portions of developers' lives are sucked.

6. Call for robust version control thirded. :)

Simes.

48 - @21 If I want to "extend" a class, say NotesDocument, by composition, I you would have to create own methods and attributes for each and every public method and attribute in the "superclass". Quite a bit of work to add or overwrite just one or two methods.

Pixel-related positioning is - although favored by web designers - EVIL. Think about 14" to 26" monitors, printers, mobile devices...


Another point: With adding flexibility you nearly automatically add complexity, and therefore the need for more knowledge (developers) and (development) time.

What makes Notes special (and better than a lot of other platforms) is the ease and speed, one could create production-ready applications.

Knowing (and using) some other "platforms" and "tools", like Java, UML, Design Patterns, Eclipse etc., I want Notes to get up-to-date in respect to language specification and IDE, but NEVER at the cost of loosing its main advantages.

Just my 2 cent
Thomas

49 - Remember the time when I read all your allways good articles in the view magazine.
The http thing mentioned comes up so often in our german forum and it is usefull as I see non-SOAP system integration via xml in the rise (POX or/and REST Webservices), which leverages a traditional strength in the Lotus architecture called document orientation. For the SOAP stuff axis is used under the hood. Why not use jakarta-commons-http client for http connections? Can't be too hard. Its robust and it has the support for all the proxy authentification, server authentification, ssl.
I second a lot the Groovy, JRuby ideas. But would prefer to see Lotus concentrating on 1 language (Groovy).
A binding framework for xml (like JAXB) would be nice.
tools for testing (unit, integration, acceptance)
What about starting a new visual workflow-tool from scratch?
As java integration has become and will be become better and better, use existing open source stuff under the hood.
Integrate one of those business rule engines.
When eclipse is there for designer, good tutorials about how to leverage the new opportunities. Its so much more than "class browsing".

kind regards
Axel

50 - Congratulations on your new position. I think Lotus Notes/Domino still has a lot of potential and I hope it can get some more attention from IBM. As an IBM Business Partner, we have been using the platform to develop enterprise applications for the health care market. Here is a list of the top five enhancements that would really add value for us.

1. Support for databases larger than 64GB, whether in NSF or DB2NSF. I know this may not seem like a programming services issue, but it really does impact application developers. We currently have to break large data sets up into smaller chunks, then write a lot of low-level code to aggregate that data for presentation to users. This is an expensive and inefficient way to work. I have had several discussions about this limitation with John Curtis and others at IBM.

2. Native XML database support (like DB2 9.1 already has). I would like to have an "XML" document item type. And then I would like to be able to issue a single XQuery query to the Domino database engine and get back the entire set of matching documents. More and more content is being generated as XML today, and this would open up a whole new class of applications. I have already discussed this with Don Chamberlin at IBM so if you're interested you may want to follow up with him.

3. Round trip DXL import and export of all design elements. Right now we really struggle with developing large applications for Domino because there is no textual source code, so we can't effectively apply standard configuration management tools. It would be great if we could export a design template to a set of DXL files, and then check those in to CVS. Unfortunately, DXL is currently missing support for certain design elements so it is useless for that purpose. (I know there are some third party source code control applications that allow multiple developers to check in and out individual design elements, but those aren't adequate for our needs.)

4. Full Eclipse IDE integration to replace the Domino Designer. They showed an early prototype of this at Lotusphere and it looked great, so it just needs to get finished. This will really improve developer productivity.

5. Support for running Java code that runs in views and forms, and accesses the Notes client user interface classes. We are trying to eliminate our legacy LotusScript code and move everything to Java, but currently we still need to have some in LotusScript for the few things that have to be done through a Notes client. If we could do everything in Java then we could eliminate a lot of duplicate code.

51 - I agree with @8 for one of my three wishes. Domino as a source for AJAX front-ends would be up there. As @15 points out, this may require HTTP integration with LotusScript but I am open to the implementation on the Domino side. I loosely envision this much like how web services evolved.

Wish #2 would be Domino as a WSRP Producer. Again, this could follow the web services model but with more structure around it.

My 3rd wish is lighter footprint PHP support. The challenge I often have with integrating Domino into other languages is that I need the Notes/Domino DLLs on the "other end". DIIOP is one mechanism for getting around this (somewhat) but perhaps AJAX or AJAX-like solutions should be the mechanism.

As you can see, all of these are "integration" related where I have applications and/or data in Domino but I need it accessible from/to outside applications. More and more, the Domino infrastructure is for "inside" work - accessible by subject and content contributors but the vast majority of end users are "consumers" and never see Domino or Notes clients. Domino really is "middleware" in this infrastructure.

52 - Very simple request-
Allow use of newline/enter key as a field exit alternative to tab.
SMB users especially those who are used to PC based apps ate used to typing the enter key to get to the next field. Plus it does speed up data entry.

Wayne

53 - That sound you just heard was the floodgates opening; I hope you have some water wings for the flood of feedback you'll be getting.

Oh, great news of course!

54 - Now this is good news - thanks! - And best of luck.

55 - @25 Axel - I would also choose groovy as the preferred jvm language (and IBM should hire them before someone else does....Jim Huginin?...Guido van Rossum?....JRuby team?) but I don't want anything that prevents the use of other languages. I would have as a goal making it easy for non Notes/Domino developers to learn Notes/Domino with whatever languages and tools work for them now. Yes you can do some of this with Eclipse now but I guess I view it as bringing Notes/Domino to eclipse rather than bringing Eclipse to Domino. I realize that this goes beyond the designer product and may not be popular with some folks but it is at the heart of programmability to me. Maybe it's time to move on from designer being a Notes client. I guess that I would be happy with designer being an Eclipse (IDE not RCP) plug-in with Expeditor and/or web as the target platform.

56 - @1 Send it!
@2 Come on! You don't need permission to send me email! (Unless it's spam...)

57 - If I was granted 3 wishes, one of them would be to ask Lotus for native AJAX support into LotusScript. I'm so frustrated with the Microsoft XMLHTTP 6.0 stuff which doesn't even run on Linux, Mac, and not even on Windows without hanging, crashing and jamming, and beeing unable to recover from network lags, responses etc...