Re: [PATCH 1/2] Support publishing build events

[Clément Lassieur]

Hi Christopher!

Christopher Baines <address@hidden> 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.