Cooperation with Cookbook

[christianlupus]

Hello,

I pinged you on Mastodon recently and saw that you have created this app. In the cookbook app, we had some issues/feature requests opened that might be related to the general idea of a grocery management:

• Add ERP-like stock management nextcloud/cookbook#2220
• Food storage management, expiration date and suggestions nextcloud/cookbook#2483

These requests sound very similar to what your app might become in the future. As I am in favor of the KISS principle and the Unix philosophy (Make each program do one thing well.), I thought it makes sense to cooperate if possible. Maybe something even better arises from this.

I first wanted to reach out and see if there is generally an interest in a cooperation present and if we should work on this, or if this is currently completely out of scope (or out of the general aim of the app). So, I first wanted to clear out general questions prior to actually starting to discuss and work on stuff. This also depends on the philosophy and the overall goal/aim of the project you have in mind.

It is not necessary to start this topic in the near future in the sense that I expect it to be implemented immediately. Instead, I am thinking it makes sense to think and discuss a general structure we might use in the future, and if we want to work together at all. If yes, we can prepare stuff and implement this in a longer time schedule.

Looking forward to hear from you.
Christian

PS: Ping @seyfeb FYI

[chenasraf]

Hey @christianlupus,

Glad you reached out! This feels like a natural fit honestly, and I appreciate the KISS framing - that's pretty much the philosophy I had in mind for Pantry too.

To answer your question directly: yes, definitely interested, and no, this isn't out of scope at all. Pantry is still stabilizing a bit (API and core features are still being fleshed out), so I wouldn't want to commit to any concrete timeline just yet - but I'm very much down to start discussing the general direction, which sounds like exactly what you had in mind anyway.

Looking at the linked issues, the two use cases that stand out are shopping list generation from recipes, and pantry/fridge stock tracking with expiration dates. I think these are worth treating separately - the shopping list side feels a lot more achievable in the near term, since Pantry's checklists can already work as one and the main thing to figure out is the integration layer. Stock tracking is a bigger thing and would need more groundwork on the Pantry side first, so I'd treat that as more of a longer-term goal for now.

I have some thoughts on both and some questions about how Cookbook handles things on its end - but I'll save that for once we've confirmed there's something worth pursuing here.

What does cooperation look like from your side? Are you thinking Cookbook calls into Pantry's API, or something more bidirectional?

[christianlupus]

First I have to admit that the shopping list is even more explicit in nextcloud/cookbook#460. There is also some work by @tobiasKaminsky done in the past. He already has an app for the shopping list that might work with our apps together. So, he might, in general, be interested in this as well.

The decision on how to access what is, in some sense, open for discussion. I do have an idea how this could work, but I have neither ironed it out nor tested it for maintainability. I try to sketch quickly:
There is the problem that each app should be runnable without errors, independently of the others. This makes it impossible to simply import foreign classes and realize communication that way, AFAIK. The NC core allows sending Events between classes and also between apps. So, I think, this is the most robust way to go at the moment.
My idea is to define some classes (aka the Events to be fired) in a common composer package. Then both apps can use it without issues and import it as a library of classes. I see at some point some handshake in the sense of Knock, knock! Is someone there? The other app would just have to register as a provider, and from there on, we should be able to use a common interface based on the events.

So, if there was in the cookbook the request (by the user) to trigger something in the pantry app, I suppose, this handshake would happen, and in the en,d there was some class that allows the cookbook code to trigger the actual action. Similarly, if you wanted to trigger some action (I am not yet sure what that might be, we can think of stuff), I would see it vice-versa.

I was thinking of testing that out with two dummy apps to see if that works or causes any sort of trouble. However, I did not find the time to carry this test out.

[chenasraf]

There is the problem that each app should be runnable without errors, independently of the others. This makes it impossible to simply import foreign classes and realize communication that way, AFAIK. The NC core allows sending Events between classes and also between apps. So, I think, this is the most robust way to go at the moment.
My idea is to define some classes (aka the Events to be fired) in a common composer package. Then both apps can use it without issues and import it as a library of classes. I see at some point some handshake in the sense of Knock, knock! Is someone there? The other app would just have to register as a provider, and from there on, we should be able to use a common interface based on the events.

Originally I was thinking simple intermediary requests using the OCS API would be both simple and efficient. We wouldn't have to know much of the internals of the other apps, and it would be simple enough to check if they are installed (e.g. checking 404 against GET /houses on Pantry)

But a hooking system is not a bad idea at all. It would definitely make it open to more apps to use in the future. Thinking more about it, it would even make a good system to base inter-app messaging on more than just our case and could easily be expanded for more apps to register as handlers for one another, which could be a cool use-case. I'm open to starting on this pair (or more) of apps but maybe leaving the door open to make it more generic (but that's for another day)

I was thinking of testing that out with two dummy apps to see if that works or causes any sort of trouble. However, I did not find the time to carry this test out.

I don't think this needs to be that difficult, simply installing feature branches of both apps on a local dev Nextcloud instance would probably be enough to start handling this sort of communication. It doesn't need to be entirely new apps, dummy or not. We'd need to work a bit on how the interface would work on the composer package and that could already open up ways to communicate between the apps pretty easily. Especially since we are talking about apps existing on the same instance and not needing to worry about anything actually external.

[chenasraf]

Hey @christianlupus,

I've been poking at how two NC apps could share state through a common Composer library, and I hit a wall I wanted to ask you about.

The issue is that each app has its own autoloader and its own vendor/, so if Cookbook and Pantry both composer require the same package, they get two completely separate copies. A singleton in one app can't see anything the other app registered - they're different singletons from different autoloaders.

The best workaround I found so far is routing everything through NC's IEventDispatcher. Each app bundles its own copy of the library but talks to the other through NC events with agreed-upon names (like latch:cookbook:recipe-shared). It works because PHP resolves methods on the actual object, not the type hint, so payloads cross the autoloader boundary fine.

The other option would be a small dedicated NC app that holds the shared instance, but that adds an extra install step which feels like overkill.

Do you know if there's a more native way to share state across apps? Some global registry apps can write to, or a pattern you've seen other apps use for this?

Any thoughts welcome, want to make sure I'm not missing something obvious.

[christianlupus]

The inter-app communication IS a problem. I tried to get there already in the past [1, 2, 3].

Yeah, my idea was to use the IEventDispatcher and related class from NC core. I had the following in my mind:

1. Define a new composer package. For the beginning, we can start with a source based one just for testing.
2. Create some basic interfaces there (maybe some data classes as well). I was thinking in the direction of AddMissingIndicesEvent. So there could be (just as an impression) a GetGroceryStorageAppEvent.
3. In instance of such an event would be dispatched by the cookbook app.
4. Each app that claims to be a grocery storage app would execute a method on the event received. The event object will store the relevant information internally.
5. After the events have all be delivered (and possible apps have called the callback), the cookbook could present the user a selection of possible apps to work with. Of course some basic information like a human-readable app name would be part of the information requested by the method call during the initial handshake.

After the initial back and forth is through (this would probably be stored in a app config value or such), it is clear with which app the communication is to be done. When an app registers itself as grocery storage app type, a few information need to be provided on mandatory level:

1. A human-readable name
2. The app id for referencing (must be stable)
3. A communication object of the app (e.g. of pantry)

The communication object is an instance of a class implementing an interface defined in the composer package. (It could be an abstract class as well but the less implementation there is, the less likely we get a problem). This interface defines a way to navigate the corresponding data set. So (as an example) it could provide a getStockOfGood method declared. Each grocery storage app could then implement their own class that does the actual data extraction/handling.
More complex structures might be exchanged using data classes defined in the composer package.

The cookbook might store which app is the user-selected default/which one is active with cookbook. The corresponsing app id is stored in the user config. Upon next invocation (where the app should be connected for whatever reason), the cookbook can requery the apps, get the correct one (based on the id) and start the communication using the communication object.

Additionally, it might be possible to give some more structure to the interface by adding more interfaces. E.g., instead of one large class with 30 methods in the sense of setters and getters of various values, a getStockManager method could return an IStockManager interface that gives access only to the current stock. An IShoppingManager would be for the shopping list (discussable if they are both grocery storage apps, but just to get the idea).

The point is: The PHP interpreter will join all classspaces into one big during execution. So, although there might be some autoloading in place and each app will have their individual set of interfaces/classes, composer/PHP/NC core will (hopefully 😉) only load the classes once and then detect that they are already loaded. As the classes must not change over time, it does not matter which class was detected first. It just needs to be present.
Side remark: Other app dependencies are not creating conflict either. So, there is some mechanism in place. All we need to ensure that the classes are always compatible in all combinations.

To get this compatibility in place, I thought about putting the verison of the API interfaces in the namespace of the interfaces. Once we need to update the interfaces for whatever reason, the changed interface will be in a different namespace and communication is cut. Only after a valid update to a common version, the communication is reestablished.

This is what I had in mind and what I intended to try out in a minimal variant. Just to see if the resolution of classes/interface works as expected and see if any obvious or non-obvious issues arise.

Does this somehow match to your expectations?

[christianlupus]

PS: I would like to create a (dummy) composer package and see if that would work. Unfortunately, I am a bit restricted in spare time these days but I will try what I can.

[chenasraf]

I have actually started working on something in this direction. I'd like to hear your thoughts on the direction, any ideas or issues you can see and raise.

The main differences in ideas I had so far are around keeping the shared layer generic (not grocery-domain-specific) and using a data-oriented approach rather than an object-oriented one. Let me explain what I mean.

I've been building a library called Latch - it's a typed hook/filter registry for PHP. The idea is that apps register as "sources" and declare typed extension points, and other apps register as "handlers" and attach callbacks to those points. There are three hook types:

• Filter - transform a payload through a chain of handlers (like WordPress filters)
• Action - fire-and-forget broadcast
• Collect - gather contributions from all handlers into a flat list

There's already a Nextcloud integration layer (BridgedRegistry) that wraps the core and bridges everything through NC's IEventDispatcher, so cross-app communication works without direct class imports - which addresses the same isolation concern you raised.

Where I think we align:

• Shared composer package as the glue - Latch itself would be that package. Both apps depend on it, not on each other.
• NC event dispatcher as transport - already implemented. When a source fires a hook, it dispatches through NC events so handlers in other apps can respond.
• No direct class coupling between apps - handlers only need to know the source ID and point name, not import anything from the other app.

Where I'd do things differently:

Your proposal defines domain-specific interfaces in the shared package (IStockManager, IShoppingManager) and has handlers return rich communication objects. I'd prefer to keep the shared layer domain-agnostic and instead use capability tags for discovery.

Here's what I mean: when an app registers as a handler, it can declare tags that describe what it provides:

$handler = $registry->registerHandler('pantry', ['grocery-storage', 'stock-tracking']);

Then the source app doesn't need to know about specific app IDs - it can query by capability:

// "who can do grocery-storage?"
$providers = $cms->collectFromHandlers('discover-providers', null, ['grocery-storage']);

Each provider responds with its name, app ID, and whatever metadata is needed. The source app picks one (or lets the user pick), and from there communication happens through the regular typed hook points.

This way the shared package (Latch) stays generic and reusable. The domain contracts (what "grocery storage" means, what data gets exchanged) can live in a thin separate package or just be conventions both apps agree on - but they don't need to be baked into the communication layer itself.

On versioning:

I like your idea of versioning via namespaces. I think we could apply a similar concept at the hook level - version the point names or tag namespaces rather than PHP namespaces, so breaking changes are caught at registration time rather than at runtime.

What I think we should do next:

1. I'll clean up Latch a bit and see if the interfaces look reasonable.
2. If you have any suggestions or rejects I will do my best to address them in the implementation
3. We could try the dummy-app test you mentioned - I think that's a good idea regardless of which approach we go with, just to validate that the class resolution and event bridging actually work across NC app boundaries
4. From there we can iterate on what the actual cookbook <-> pantry (and other apps) contract can look like

Let me know what you think. And I would love to have you as a contributor so if you're willing (in whatever time you feel like it ) then just let me know and I'll give you permissions the repo.