Re: libseed-list libseed is disappearing and what can we do about it

[Alan Knowles <alan akbkhome com>]

Replies in-line..

On Saturday, February 27, 2016 12:40 AM, Danilo Cesar Lemes de Paula wrote:
> Hi folks,
>
> I want to start this email with an important consideration:
> Seed is dead, long live Seed!
>
> I was looking for projects using seed, and looks like that at least in
> Debian libseed is long gone. It's still being packaged on Fedora, but no
> one is using it.
Without a reasonably popular dependent package, I guess that there is 
little motivation to package it.. Classic chicken/egg problem..
> Looking for rdepends seed it's not required by anyone. Libpeas was using
> it a while back, but they removed the dependency so we lost epiphany,
> our last important user.
>
> Considering that, I have a proposal:
>
> Killing it the way it's now and making it a new tool.
> At Collabora,  seed is an important component for a project and we are
> willing to maintaining it. However, we would like to propose to drop
> some parts of it and using the GJS compatibility mode as the default
> mode. Since seems that there's no other project using it, it might be a
> good idea.
My only dependencies on seed are
a) the code that generates the documentation for our Javascript library 
- this may be converted to vala  eventually though. [1]
b) the documentation for seed and gjs, which I very very occasionally 
update... [2]

Neither of which are that complicated to change if you change the 
API/ABI etc..

You may as well keep calling it seed...  and just break the API/ABI.. 
bump the version etc.. I doubt it's really going to see more of an 
adoption in it's current iteration.

> So, the plan would be:
> We won't care about ABI break at this point. The API will probably
> change considerably. Some components like SeedEngine shouldn't be a
> global entity anymore and probably be a GObject.
> Private header will be private, so no more header duplication...
> Also, seed seems to care about some old behavior that I think we should
> drop completely.
Not that fussed on this, I've only seen a couple of bug reports about 
changing the SeedEngine API over the years, not sure if those project 
that where using it are still alive.
> That being said, I would like to think that the final goal would be to
> make seed comparable to gjs, feature-wise. And, of course, allowing gjs
> (which is the de facto javascript engine for gnome) code to run on seed.
There are quite a few benefit's to this... - gnome shell comes to mind, 
and anyone scripting webkit might benefit from a reduced library overhead..

A bit of redundancy in picking JS engines for those projects would 
always help..

> I'm not seeing much movement in this mailing list, so I'm also inviting
> Alan and some old Maintainers to the discussion.
>
> I know you guys did a lot of work on it, and I'm sure you want to see it
> being used again.
I say that about all the projects I work on ;) - although my user base 
usually ends up with 3 people ...

Regards
Alan

> That's it guys,
>
> Cheers,
>
> Danilo
[1] https://roojs.com/roojs1/docs/
[2] https://www.roojs.com/seed/gir-1.2-gtk-3.0/seed/