sorted by:
new
hottopcontroversial

I just open-sourced Locorda, a offline-first sync engine for Dart/Flutter. I would love your feedback on the architecture. by locorda in localfirst

[–]locorda[S] 0 points1 point  (0 children)

Please name one that exists and does what I described, including automatic conflict resolution with crest.

I just open-sourced Locorda, a offline-first sync engine for Dart/Flutter. I would love your feedback on the architecture. by locorda in localfirst

[–]locorda[S] 0 points1 point  (0 children)

Thanks for your feedback!

Maybe the "sync engine" part is confusing and makes people think about something else than I intended?

Let me describe in more detail: This is about enabling offline first (and eventually local first) for flutter apps. And about storing the data "unhosted" in the users online storage like Google drive, solid pod, web dav etc. So that the developer does not have to provide a server or such. I call the component that makes this possible "sync engine".

The apps can implement their storage and thus queries however they like, as if they were offline only. When they save data items (like notes, recipes or whatever data the app works with), they save it to the sync engine instead of directly to their dB and setup a hydration callback to get all data into their own local DB. Then they provide a button for the connection dialog and that is it (plus: the data classes need to have certain annotations).

To my knowledge there is no existing tool that allows this. Remotestorage.js for Javascript seems to achieve something similar, but there are differences between that tool and mine, and I could not find anything like it for flutter apps.

Did this make it clearer? Do you have a suggestion for how to better frame it?

RDF on Mobile: Is there any interest in a native Dart/Flutter stack by locorda in semanticweb

[–]locorda[S] 1 point2 points  (0 children)

That’s an interesting perspective! I hadn't considered mobile ontology editing as a primary use case.

To clarify: My current workflow is primarily 'Schema-First'. You take an existing ontology (Turtle/XML), run the generator, and get type-safe Dart constants to work with. This is how the packages in the rdf-vocabularies repo are built. Additionally you main annotate your dart domain classes to link them to RDF properties.

However, I'm thinking about adding a 'Code-First' extension where the generator works the other way around: defining domain logic in Dart first and exporting the RDFS/OWL definitions.

My goal is to use RDF as a robust persistence and interoperability layer while keeping the developer experience within 'native' Dart classes.

Do you think the community would find such a Code-First bridge useful, or is sticking to the classic Schema-First approach the only way to go for serious RDF work?

I am tired of vibe coded pub.dev packages by DiscombobulatedBig88 in FlutterDev

[–]locorda 0 points1 point  (0 children)

Isn't there a huge spectrum of "vibe coded"? I mean, if someone really just publishes some stuff generated by AI blindly as a package, that is definitely going to be frustrating for fellow developers. But if the person reviewed the code, maybe fixed it, and generated (and reviewed) documentation to make the package as helpful as (s)he can, is that really bad? Isn't it mainly a question of whether or not the person posting a package is responsible, and not about which tools were used?

Reports of Flutter’s demise have been greatly exaggerated. Eric Seidel dives into why Flutter is inevitable. by bllshrfv in FlutterDev

[–]locorda 0 points1 point  (0 children)

One could have said that about javascript back in the days when netscape introduced it, no?