frg_Away: ugh multi-site is HARD

when it is more than just determining the application for an add-ons site

I had this brilliant idea of half my sites being driven by the same instance of a multi-site acendeded phoebus site.. and I shall have it but it is HARD lol tho that will make it even more impressive but still lol

in design not function

*

there are also different apis

oh for add-ons stuff specifically

well technically 3 if you count my own crap

four if you count older umo stuff from 2005

and 6 if you count latest vs abtn transitory state

frg_Away: I'll cover em all eventually it is a new dream of mine but late model toolkit/olympia and early model webex shit gets my coding priority for the actual phoebus successor as for my general php well multisite is still hard lol

I think we are more or less von version 3 of the current mozilla version but unsure. Fx is at 4 I think.

tho the application doesn't use much of the true api largely older style endpoints from remora and the like i believe

for SM and even abtn current

that are maintained

versioncheck.abtn discover api etc

not the olymia api like search uses

err

zamboni impala olympia

the python add-ons site api.. much of that remained unused in-codebase

and tends to stick to remora and umo older endpoints

i term that amIntegration add-ons manager integration .. namely aus both rdf and json .. the search api.. discovery api.. and not much else actually as far as the Add-ons Manager goes frg_Away

sure there is add-ons sync but that isn't reliable across impls

and can't be done independantly.. we have tried

but yeah.. you don't need the abtn api to do the add-ons site service you only need the classically mozilla-y endpoints of yesteryear largely

plus the logic to do it all and the vision to make it happen..

i just dunno which all was in play either after 52 or as a result of your patch queue but I am excited to find out more so than ever

I always figured Mozilla would just make the Add-ons Manager consume the amo api directly in a much more complete way and just kinda showroom the public website

like Add-ons Manager as an AMO Client

it seems that is what the api seems to be bent on allowing but it has not happened that way or been taken over by unrelated newer services

guess it was just too much for Maniel to take

MattATobin we tried to update the addon manager code to 60 without breaking an egg. webext works more or less ok in a Firefox build and the classic stuff too. Probably need to go with some stuff even further but after 60 add-on biotope was practically destroyed.

well i know you need webex not that it is assured you have what any arbitrary webex extension needs but yeah dude just avoid the add-ons manager from the pach queue if you can once we get going on making it useful for SEAMONKEY users or anyone else not mozco lol

I am familar with the code from a purely development stance both 38 and 52's and yours isn't much newer than that one

tho newer incarnations become a bit more tangled and harder to follow but yeah

webextensions as far as the add-ons manager and xpi providr ara conserned is largely trivial.. the webex support is more in toolkit and fe components

but you know that frg_Away just making sure everyone else does too ;)

as well as .. questionable holes punched in older modules and junk

I wish Mozilla had just .. changed jetpack to work like webextensions and left the otehr tech alone or at least extensiably open if it all otherwise were not to change

frg_Away:

your daily reminder to Push! Things! Forward!

tomman: even if I have to do it while they are kicking and screaming?

or is that especially?

hey I am flexable.. I can shoot you now.. or wait until we get home

related: I just spotted this gem at Hackernews: "Rust also attracts good developers in general, moreso than the average language certainly."

sigh

news.ycombinator.com/item?id=37965947 on a post about Ruffle, the project that told me to pound sand when I DARED reporting a easily fixable compatibility bug

(and also got a threat to use more Chromeisms)

tomman: eh, are they backing that with what? is there actually some difference regarding people reaching for rust?

it's Hackernews' Rust Evangelism Strikeforce Team

you're not allowed to say mean things about Rust on HN

njsg_: yes it means shitty code on a shitty compiler written by shitty people who would tell you to killyourself if it didn't violate the coc they been sucking on for ever so long

one thing is saying mean things, other thing is boosting Rust without an actual reason to

but i am gonna stop there cause it ain't good for me to continue down that line of connnversation so sorry

HN will praise all things Rust for no reason, and you're being downvoted into oblivion if you dare arguing with solid reasoning

yeah sorry for the vial negativity .. isn't even orginal vial negativity

it's like the (now) old meme that all memory leaks and stack overflows ever will get fixed if we rewrite the world in Rust

I would say they believe that like we all believe in xul.. BUT they have no passion or soul

most of us still do

they believe it cause they were told to

we all do this deadend amazing shit everyone hates because we simply.. KNOW BETTER

that is how I figure it anyway

tomman njsg_ frg_Away

any thoughts against or for that conclusion?

welp enough being angry at the modern world for the moment.. I have to create alternatives lol

we will know in a few years if rust is cool. My prediction is that not many will be able to decipher the old code and a support nightmare will happen.

well these days shit that is known to fail and be laughably unsuitable is continuously pushed until it fuckin collapses or someone puts a stop to it.. that is my fear with rust

that it will outstay its welcome even for the most indoctrinated

and we will be forced to deal with it forever

frg_Away: MY OTHER FEAR is that mozilla will use rust to js back to rust

conversions and bytecoad and shit

in same insane combo as an experiment and it will never be fully removed after it fails

that kind of shit

rust to fe js bytecode to be ran by the js engine which is half-rust by then

so that a direct js change in a mozilla application can't even be done OR if it can one can't actually resolve the rust to actual js or actual js that would work

you know how mozilla loves codegen, transcoding, and bytecode shit now a days

but like i said.. i have alternatives to fabricate

peace