Hi Christopher! Christopher Baines <m...@cbaines.net> writes:
> I guess so… I was probably just thinking about JSON from JSON fields > in PostgreSQL, but we're not using PostgreSQL here. > > The one advantage I can think of is that not every Scheme object can be > converted to JSON (at least with guile-json), so by storing the JSON > representation, you're guaranteed to have a valid value. If you stored a > scheme object, there's a chance that you could store something that was > invalid, or at least didn't convert to JSON. Do you know any Scheme object that cannot be converted to JSON? Even procedures can. >> But in that case, why not fetch them from the Guix Data Service? > > I'm still not sure what the ideal scope and architecture for the Guix > Data Service, or Cuirass is, but at the moment I've been trying to avoid > making one dependent on the other. Well, if we want to keep our softwares (GDS and Cuirass) as simple as they can be, there should be a clear delimitation about what each of them does, and they should not implement the same features, in my opinion. Also, I can't see how GDS wouldn't be dependent on Cuirass. So maybe I'm wrong, but if GDS stores the events, I think it's a bad idea that Cuirass stores them too. > Also, I've been thinking about WebSub when trying to provide a way to > subscribe to events, which I'll say more about shortly… I'd love to understand what WebSub is too! >> Now that I think about it, I don't understand the point the HTTP API >> ("build-events", "evaluation-events"). If events are sent from Cuirass >> to the Guix Data Service, why would anyone need to fetch those events >> from Cuirass? Wouldn't it make more sense to fetch them from the Guix >> Data Service? > > So, while this work is trying to copy data from Cuirass to the Guix Data > Service, I'm still thinking about them separately. I guess if you're > running your own instance of Cuirass, you might want to fetch events > from it, without having to setup an instance of the Guix Data Service. Is there any use of having raw Cuirass events without the Guix Data Service to interpret them? >> Why do we need to use a fiber, if there is only one? A fiber is a >> lightweight thread. They are useful if we need to do several things in >> the same time, but if there is only one thing to do, I don't understand >> the point. > > If I remember correctly, the way Cuirass accesses the database is tied > up with fibers, so it's to make the database access work here. It's not tied up with fibers. There is a database server in another thread, and WITH-DB-CRITICAL-SECTION will allow you to communicate with that server through channels. But you don't need to be in a fiber to communicate through channels, being in the main thread is good enough. Clément PS: sorry to have sent my review so late, I couldn't find the time before.