In my experience working with Notes over many years, it was a neat architecture let down by client UI that did not meet the expectations of users who also used, for example, MS Office apps. Often, they were cosmetic things. But Notes enabled workflow applications like email on steroids; Microsoft leveraged all it could to displace Notes with Exchange and SharePoint, both IMO technically not as good as Notes in many areas, but the Outlook UI was much better than the Notes client for email, and together with the marketing push, client-side Notes was finished. Domino could perhaps have survived, but it needed more than the anaemic LotusScript and formula language to get support from developers, and that never happened.
I agree with everything but the UI part. I think it was on par with Office. I used both at the same time. This is if you are compering Outlook, the email client, with the email app in Lotus Notes. As Lotus Notes was much more than email client. I was just the other day talking about Lotus Notes and Outlook. Lotus Notes had 3 different ways to look for info, the most powerfull one being indexing the database. My friend was praising how good Notes search was vs Outlook that never seem to find anything.
Lotus Notes Supported Formulas, LotusScript and Java.
I've only ever used Notes as a mail client, at a company I did consulting work for decades ago, for most of the 00s. (Yeah, sure, we'd heard that it was more than an email client -- but what did we care, when we didn't use it for anything else?)
Based on that, I absolutely disagree with your take on the UI: It was slow, clunky, ugly, and confusing. That was probably a (the) large(st) reason why they switched to MS Outlook.
If that was the period UI you meant, you're just wrong. Either you must have meant something newer, or you've suffered, what's it called? I think there is a name for the phenomenon, having your expectations lowered to the level of what you're getting.
I think it's important to start by saying that using Lotus Notes only as an email client misses the bigger picture, as Lotus Notes was was so much much much more than that. IBM had thouthands of custom made apps running on Lotus Notes. I had built about 50 apps.
Also, you didn't mention when you used it. I worked with Lotus Notes from 1995 to 2010, and the experience really depended on the hardware available at the time. Once it was up and running, it performed just fine if you had enough memory. For example, I still have version 8.0.2 (from 2008) on my machine, and it uses roughly 13MB at idle and up to about 50MB depending on installed apps, which isn't much by modern standards. But back in 1995, when 8MB of RAM was common, if Notes took up 6MB, I can see how that would have been a real issue. In my case, my ThinkPad had 32MB, then 64MB, and even 192MB which is the moment I installed Windows 2000.
As for the UI, the email client was highly configurable. Honestly, I don't remember ever thinking that something like Netscape Mail or The Bat looked or any email client that I tried at the time looked better. I didn't use Outlook back then, so I can't compare directly, but if Outlook over the past decade is any indication, Lotus Notes was at least on par, if not better that it.
What's really surprising is that even today, Lotus Notes had features that many modern clients still lack. For example, you could select multiple emails and forward them all together in a single message. Simple, but incredibly useful, and not something you commonly see implemented even now.
Later versions of Domino also had full Java support, so you could write applications in that language and just use Domino as a back end database. But you still had to do semi-manual memory management, which made it tough for most Java programmers.
The works of Elleston Trevor, writing as Adam Hall, are also worth a look. His protagonist is named Quiller, and perhaps the best known work is "The Berlin Memorandum" adapted into a film titled "The Quiller Memorandum".
Other libraries are available: distlib is even part of PyPA, but apparently its approach to trying out new things put some people off, so it's not "blessed". It supports legacy, standard and semver versions in its version module [0].
>>> from distlib.version import LegacyVersion, NormalizedVersion
>>> NormalizedVersion('2.4.0cloudera2')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/disk2/vinay/projects/scratch/distlib/distlib/version.py", line 33, in __init__
self._parts = parts = self.parse(s)
^^^^^^^^^^^^^
File "/disk2/vinay/projects/scratch/distlib/distlib/version.py", line 276, in parse
result = _normalized_key(s)
^^^^^^^^^^^^^^^^^^
File "/disk2/vinay/projects/scratch/distlib/distlib/version.py", line 188, in _pep_440_key
raise UnsupportedVersionError('Not a valid version: %s' % s)
distlib.version.UnsupportedVersionError: Not a valid version: 2.4.0cloudera2
>>> LegacyVersion('2.4.0cloudera2')
LegacyVersion('2.4.0cloudera2')
The CFG configuration format is a text format for configuration files which is similar to, and a superset of, the JSON format. It's not new - it dates from well before its first announcement in 2008 - and has the following aims:
* Allow a hierarchical configuration scheme with support for key-value mappings, lists and basic types such as strings, ints, floats, Booleans and date/times.
* Support cross-references between one part of the configuration and another.
* Provide a string interpolation facility to easily build up configuration values from other configuration values.
* Provide the ability to compose configurations (using include and merge facilities).
* Provide the ability to access real application objects safely, where supported by the platform.
* Be completely declarative.
It's similar to newer formats such as JSON5, HJSON, HOCON and similar but offers a number of features [0] which they don't, as indicated by the above list. It's not intended to occupy the niche where you find things like Cue, Jsonnet, Dhall and similar.
It was just never especially publicised when first implemented for use in Python projects, but it now also has implementations for the JVM, .NET, Go, Rust, D, JavaScript [1], Ruby and Elixir (all BSD-3-Clause licensed) and it would be great to get feedback on the project from the HN community.
I developed a configuration format which is similar to, and a superset of, the JSON format. It's not new - it dates from well before its first announcement in 2008 - and has the following aims:
* Allow a hierarchical configuration scheme with support for key-value mappings and lists.
* Support cross-references between one part of the configuration and another.
* Provide a string interpolation facility to easily build up configuration values from other configuration values.
* Provide the ability to compose configurations (using include and merge facilities).
* Provide the ability to access real application objects safely, where supported by the platform.
* Be completely declarative.
It's similar to newer formats such as JSON5, HJSON, HOCON and similar but offers a number of features [0] which they don't, as indicated by the above list. It's not intended to occupy the niche where you find things like Cue, Jsonnet, Dhall and similar.
It was just never especially publicised when first implemented for use in Python projects, but it now also has implementations for the JVM, .NET, Go, Rust, D, JavaScript [1], Ruby and Elixir (all BSD-3-Clause licensed) and it would be great to get feedback on the project from the HN community.
Just under their table of contents, they say that "This list is fairly outdated." and point you to https://github.com/xflywind/awesome-nim - and that repo seems to have recent updates.
The pagesign module (named from ‘Python-age-sign’) allows Python programs to make use of the functionality provided by age [1] and minisign [2]. Using this module, Python programs can encrypt and decrypt data, digitally sign documents and verify digital signatures, and manage (generate, list and delete) encryption and signing keys.
The CFG configuration format is a text format for configuration files which is similar to, and a superset of, the JSON format. It's not new - it dates from well before its first announcement in 2008 - and has the following aims:
* Allow a hierarchical configuration scheme with support for key-value mappings and lists.
* Support cross-references between one part of the configuration and another.
* Provide a string interpolation facility to easily build up configuration values from other configuration values.
* Provide the ability to compose configurations (using include and merge facilities).
* Provide the ability to access real application objects safely, where supported by the platform.
* Be completely declarative.
It's similar to newer formats such as JSON5, HJSON, HOCON and similar but offers a number of features [0] which they don't, as indicated by the above list. It's not intended to occupy the niche where you find things like Cue, Jsonnet, Dhall and similar.
It was just never especially publicised when first implemented for use in Python projects, but it now also has implementations for the JVM, .NET, Go, Rust, D, JavaScript [1], Ruby and Elixir (all BSD-3-Clause licensed) and it would be great to get feedback on the project from the HN community.
All rights reserved.
Copyright (c) 2020 Lucian Marin
It was the MIT license at the time of initial commit, and been updated to this. So it's not immediately clear if anyone else can necessarily use Logparser - care to clarify, Lucian?
I've started playing around with Tailscale [1], which is based on WireGuard. Free to use for a single user, and I've tried it out on Raspberry Pi, Linux x86_64, Windows and Android. Seems to work well, except there appears to be some issue with accessing Windows via the secure IP (neither ping nor Remote Desktop appear to get through the Windows firewall, despite having a specific firewall rule for Tailscale) [2]. Can SSH into e.g. Linux hosts using PuTTY from Windows without issues.
reply