Mapy.com does this and I often see and resolve these notes on streetcomplete. It's nice setup, they provide a suggestion and location, it takes little effort to check if you are walking by and just reply to the note. Some enthusiastic editor (can be you back home, but it's annoying to do on a phone screen) then can make the edit and resolve the note.
Yes, the data source is clearly useful, so not having it is a loss. But an edit is large enough a privilege to require all these checks.
Perhaps it's not that OSM that needs a signal, but perhaps it's that there's an opportunity for an open map that has many signals, of which OSM and Book Corners are examples.
Laying your own datasets on top of OSM is probably the most common use case. OSM isn't much of a replacement to Google and Apple maps as it is a way to build your own custom maps.
This can probably be added to the toolchain pretty easily when non-OSM "signals" are converted to OSM format first. All you need then is an OSM data merging tool, all other tools will then get the same data format as before.
SwiftData is just a framework that you can choose to ignore and not use at all. Even CoreData.
You can go straight to the source, and use some small layer on top of SQLite, and ignore that noise (most large apps just do that).
But, SwiftUI is being pushed as the way to do UI, and as a replacement for UIKIt/the future of apple, where it is not even near feature parity with it. That's the most troubling part of it.
I wished apple just made it as a Template Rendering framework, and integrated wit with UIKit, and just modernized UIKit a bit.
Agreed. SwiftData is terrible for anything more than like 2 "Models". I have a bunch of apps written with SwiftData and a bunch more with GRDB... I hate touching the SwiftData ones.
just want to say, whether you like the name/admin or not those accounts are a very good deal. Setting up one for a new born is a get-out-financial-mistakes (cc/student loan debt etc) free card when they grow up and get access to the money. If you're smart and can make some decent deposits in the first year or two that could easily become a buy-a-house-for-free card which would be an absolute treasure for kickstarting a young person's financial life.
It's too late for my kids but if i'm ever lucky enough to have grandkids part of their bday and Christmas gifts will be deposits.
An executive order declaring a newly created legal entity is now the holder of all previous debt. The new entity has no assets or revenues, other than Trumpcoin.
This is reminiscent of the operating system wars and browser wars. In the end there will only be 2 models that can survive. 1: give it away for free or 2: locked in with top notch hardware.
Not for every situation. CLI is great for coding agents (and I'd agree, far better in most cases than MCP). But it requires some execution runtime somewhere to actually run. So for app use cases where you don't want to build out your own tools for every integration, MCP can be a solid option.
Also, in my opinion, it's much easier to build a good MCP interface than it is to build a good CLI interface - and afaik there's support for MCP tools to return things like images from an MCP tool call directly to the calling LLM that is a bit tricker to do via CLI.
There is definitely some debate going on on mcp/cli/api etc, but is quite obvious that mcp is being adopted as standard for integrating third party applications to the major clients => chatgpt apps, claude connectors, mistral, cursor etc.. they all connect to external apps using mcp. Of course it's possible for you to tell claude to use some cli directly but it's much easier to connect the mcp with one click
I've been sitting in the same camp recently. We maintain both an internal MCP and CLI for our app which our devs use locally. The CLI so far feels like a much smoother experience both in terms of setup, control and performance.
But i can see how MCP being able to plug into a remote agent that doesn't have terminal access is very useful. Seems like it's a best tool for the job conversation or am I missing some other advantage?
CLI certainly is better than local MCP. But nowadays, most MCPs are remote and the comparison fall short, at the notable exception of `gh` in a coding environment. But having CLI already authenticated is not guaranted either!
MCP makes a lot, lot more sense when you think of it as as a auth standard and not a comparison with CLIs. It obviously does more than just auth, but having standardised auth (which CLIs definitely do not) is the real 'killer' feature.
Yep, that was exactly my point with the ask to elaborate.
MCPs and CLIs feel like two wholly different things. Contrasting them feels even more confusing than comparing Skills vs MCPs, which would also be wrong in my personal view. Different runtime requirements, different access patterns, different distribution, different discoverability.
I agree with @martinanld that MCPs, especially with the advent of EMA, are a completely different beast thanks to a structured way for auth and access control.
I am so tired of people repeating this. Usually, this results from conflating two uses of MCP: local, which can indeed be replaced by CLI (and you can argue which one is better), and remote, which is entirely different, and there is no way to replace it with a CLI (note that you are making an implicit assumption that a CLI tool can be used at all, which is not always the case).
Please don't repeat this. It's like saying that apples are dead and oranges are the future.
Explain again why a cli can't access a remote service ?
The only difference that is not superficial is the token count. Everything else : format, doc, auth, discoverability, ... can be made the same (the cli could be an mcp client, and the mcp server could implement a local shell, after all)
> Tell me you don't understand what you're saying without telling me you don't understand what you're saying.
Please don't cross into personal attack, regardless of how wrong someone is or you feel they are.
Your comment would be fine without that last swipe, and even better if you had gone on to say what the two purposes are. Then we could learn something from it.
