Deprecate unused libraries

[Hywan]

Hello fellow Hoackers,

As discussed yesterday during the Hoa Virtual Meeting, and since several days now, we would like to deprecate some libraries that are either (i) un-used/unpopular, (ii) not relevant anymore because they refer to dead technologies. The goal is to reduce the maintenance, the effort of documentation, testing etc.

To decide what libraries to deprecate, we need data. Here they are:

libraries	downloads	stargazers	forks	has no composer.json	agreed to deprecate
hoa/acl	163	21	11
hoa/bench	9665	50	8
hoa/cache	18	7	7		•
hoa/cli	8748	10	5
hoa/compiler	818688	152	30
hoa/consistency	378461	22	7
hoa/console	68105	264	24
hoa/core	633775	38	23		•
hoa/database	631	14	15
hoa/devtools	2288	4	8
hoa/dispatcher	52730	7	8
hoa/dns	162	22	7
hoa/event	376436	21	6
hoa/eventsource	6361	74	17
hoa/exception	375866	21	7
hoa/fastcgi	7873	17	8
hoa/file	850661	30	11
hoa/graph	364	7	7
hoa/heap	6	4	2
hoa/http	70021	5	10
hoa/irc	184	18	8
hoa/iterator	862256	41	11
hoa/json	1037	9	5
hoa/kitab	471	63	6
hoa/locale	2291	11	7
hoa/log	0	3	6	•	•
hoa/mail	1418	20	10
hoa/math	815860	93	33
hoa/memory	0	4	4	•	•
hoa/mime	59519	84	12
hoa/model	0	2	7	•	•
hoa/notification	0	3	5	•	•
hoa/option	21	3	3
hoa/praspel	14768	30	8
hoa/promise	26	3	3
hoa/protocol	359472	20	6
hoa/prototype	0	2	4	•	•
hoa/realdom	14781	5	7
hoa/regex	773549	32	10
hoa/registry	10495	11	9
hoa/router	52643	25	13
hoa/ruler	691941	466	51
hoa/serialize	15	3	4		•
hoa/session	2887	9	11
hoa/socket	73691	52	24
hoa/stream	959962	21	11
hoa/string	51965	6	3
hoa/stringbuffer	5832	3	6
hoa/test	2005	12	10
hoa/translate	26	3	5		•
hoa/tree	16	4	4		•
hoa/ustring	753542	123	12
hoa/view	6174	6	7
hoa/visitor	812469	14	8
hoa/websocket	55793	403	69
hoa/worker	235	20	11
hoa/xml	2429	6	8
hoa/xmlrpc	12	3	7		•
hoa/xyl	2386	6	11
hoa/zformat	293886	11	4
hoa/zombie	279	26	8

My next comment will propose some libraries to deprecate, and why.

[Hywan]

First, I think we can deprecate all libraries that have no composer.json file because it means they are not use by anyone in the PHP world basically. I explain why:

• hoa/log: We can't fight monolog, that is the king in this area. Also, no revolution to expect or to bring in this domain (for PHP I mean),
• hoa/memory: This was an attempt for something, but it's not finished, safe to drop,
• hoa/model: When Hoa tried to be a complete framework toolbox, never correctly designed, other libraries do a better job, this is not our confort zone anyway,
• hoa/notification: Never finished. One day, maybe, but not today, not in a close future,
• hoa/prototype: Should already be deprecated. It was a joke that PHP could has a prototype model just like Javascript.

Second, I would like to deprecate libraries addressing a dead technology, like:

• hoa/xmlrpc: We all agree that XML-RPC is dead. People mostly use SOAP in the industry (its competitor), or JSON-RPC, or BSON, or ProtoBuf, or Message Pack, or…

Third, libraries I'm not sure if it is relevant to keep:

• ❓ hoa/worker: This library is cool but nobody continues to use PHP for workers, am I wrong?
• ❓ hoa/tree: This library is incomplete regarding features people would like to have, it is so basic right now that it is not interesting,
• ❓ hoa/translate: The Gettext backend is great, but I'm not sure we will support more industrial standards in a close future + ext/intl is far more rich and is almost native now,
• ❓ hoa/irc: PHP is not async, so having a good IRC library to do bots & co. is difficult. I'm not sure. Also, there is no real IRC library for PHP after a quick search on Packagist. Maybe we have a card to play,
• ❓ hoa/cache: I never needed it yet. Am I the only one?

[Grummfy]

no composer => drop : OK

• hoa/worker : people (me at least in 3 company I have worked in) use worker in php. So it could be interesting, But yes usage evolved a lot.
• hoa/tree : not aware it exist ;) can be interesting but except if you have a lib that use it and connect it to some data model or something similar, I don't see the intrest...
• hoa/translate => a lot of lib exist and are coherent, most of the time you use the one provided by your framework
• hoa/irc: there is not that much library that exist, perhaps I would keep it and check for the "bot" project that exist now to see if we can integrate it inside as an extension/plugins? For me I'm in favor to keep it, even if we only maintain it basically for now
• hoa/cache : for me creating a cache is quiet simple, most of the time you use the one provided by your framework. Except if we got real plus, I don't see the interest to keep it.

[Pierozi]

👍 drop no-composer

• hoa/worker: has an interesting way to run different job and communicate with it.
  Even if in the today world, message broker as rabbitMQ are preferred to schedule job. It can be still interesting in specific use case.

These can be deprecated too? :

• hoa/xyl
• hoa/serialize

[Hywan]

• hoa/serialize is nice, more like a joke, but I agree yes, we should deprecate it,
• hoa/xyl must not be deprecated until W3 (Hoa's website) and hack books are using it. The plan for hack books is to replace them by Kitab. Once this is done, then we can move W3 to another template engine than XYL. But yes, I woud like to see XYL deprecated.

[Hywan]

I've updated the first comment with a new column to the table: “Agreed to deprecate”, just to keep track of the discussion.

[Grummfy]

hoa/heap ?

[Hywan]

No, it's a new library, which explains the low number of downloads and stars.

[vonglasow]

Hello,

agreed if everyone here.
❓ hoa/worker: As it looks used by @Grummfy and still in way of time maybe keep it for now. We will see for next evolution after
❓ hoa/tree: Can drop
❓ hoa/translate: Can drop
❓ hoa/irc: It's used by Marvirc what about this tool ? Do we remove it also ?
❓ hoa/cache: Can drop

What about

hoa/database: ? For me we can mark it as deprecated also

[Grummfy]

Precision: I don't use hoa/worker, I just say I do worker in php and use stuff like this in several jobs.
I have no specific point about keeping it or not.

database can be drop for me

[Hywan]

I would like to keep hoa/database because some projects use it.