hoaproject/Central

Deprecate unused libraries

Hywan opened this issue · 20 comments

Hywan commented

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 commented

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?
  • 👍2
Grummfy commented

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.
  • 👍1
Pierozi commented

👍 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 commented
  • 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.
  • 👍1
Hywan commented

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

Grummfy commented

hoa/heap ?

Hywan commented

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

vonglasow commented

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 commented

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 commented

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

Pierozi commented

It's true that hoa/database are bit simplistic but I'm fine to keep it, it has the advantage to be really light with a minimum overhead of Php native functions.

Hywan commented

OK, let's deprecated :-).

Hywan commented

hoa/cache

hoa/log

hoa/memory

hoa/model

hoa/notification

hoa/prototype

hoa/serialize

hoa/translate

hoa/tree

hoa/xmlrpc

  • 👍1
Hywan commented

Website has been updated accordingly, https://hoa-project.net/.

Thanks!

@vonglasow Could you update the mirrors please?

Hywan commented

@shulard Should write a blog post about that?

vonglasow commented

@Hywan yes for sure.

Mirrors on Gitlab are archived,
On Pikacloud, this functionality doesn't exist. I can only make it private or delete it. What would you prefer ?

shulard commented

@Hywan, yep I try to write that article before the end of the week 😉.

Hywan commented

@vonglasow I think deletion is fine.
@shulard 👍!

  • 👍1
vonglasow commented

All deprecated libraries are now deleted from the mirror pikacloud

shulard commented

I've created the article here : hoaproject/Blog#20.