12:46:58 <MattATobin> frg_Away: ugh multi-site is HARD
12:47:17 <MattATobin> when it is more than just determining the application for an add-ons site
12:48:46 <MattATobin> 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
12:49:04 <MattATobin> in design not function
12:49:06 <MattATobin> *
12:49:14 <frg_Away> there are also different apis
12:49:31 <MattATobin> oh for add-ons stuff specifically
12:49:41 <MattATobin> well technically 3 if you count my own crap
12:49:51 <MattATobin> four if you count older umo stuff from 2005
12:50:04 <MattATobin> and 6 if you count latest vs abtn transitory state
12:51:38 <MattATobin> 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
12:52:27 <frg_Away> I think we are more or less von version 3 of the current mozilla version but unsure. Fx is at 4 I think.
12:53:42 <MattATobin> tho the application doesn't use much of the true api largely older style endpoints from remora and the like i believe
12:53:50 <MattATobin> for SM and even abtn current
12:54:04 <MattATobin> that are maintained
12:54:25 <MattATobin> versioncheck.abtn discover api etc
12:54:40 <MattATobin> not the olymia api like search uses
12:55:04 <MattATobin> err
12:55:25 <MattATobin> zamboni impala olympia
12:55:45 <MattATobin> the python add-ons site api.. much of that remained unused in-codebase
12:56:05 <MattATobin> and tends to stick to remora and umo older endpoints
12:57:37 <MattATobin> 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
12:58:18 <MattATobin> sure there is add-ons sync but that isn't reliable across impls
12:58:31 <MattATobin> and can't be done independantly.. we have tried
12:59:09 <MattATobin> 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
12:59:49 <MattATobin> plus the logic to do it all and the vision to make it happen..
13:00:47 <MattATobin> 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
13:01:59 <MattATobin> 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
13:02:26 <MattATobin> like Add-ons Manager as an AMO Client
13:03:03 <MattATobin> 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
13:10:43 <MattATobin> guess it was just too much for Maniel to take
13:35:25 <frg_Away> 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.
13:42:42 <MattATobin> 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
13:43:48 <MattATobin> 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
13:46:04 <MattATobin> tho newer incarnations become a bit more tangled and harder to follow but yeah
13:47:50 <MattATobin> 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
13:48:05 <MattATobin> but you know that frg_Away just making sure everyone else does too ;)
13:48:43 <MattATobin> as well as .. questionable holes punched in older modules and junk
13:49:46 <MattATobin> 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
13:49:49 <MattATobin> frg_Away:
13:52:05 <tomman> your daily reminder to Push! Things! Forward!
13:54:11 <MattATobin> tomman: even if I have to do it while they are kicking and screaming?
13:54:33 <MattATobin> or is that especially?
13:55:06 <MattATobin> hey I am flexable.. I can shoot you now.. or wait until we get home
13:55:13 <tomman> related: I just spotted this gem at Hackernews: "Rust also attracts good developers in general, moreso than the average language certainly."
13:55:37 <MattATobin> sigh
13:55:42 <tomman> https://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
13:55:58 <tomman> (and also got a threat to use more Chromeisms)
13:56:12 <njsg_> tomman: eh, are they backing that with what? is there actually some difference regarding people reaching for rust?
13:56:31 <tomman> it's Hackernews' Rust Evangelism Strikeforce Team
13:56:49 <tomman> you're not allowed to say mean things about Rust on HN
13:57:08 <MattATobin> 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
13:57:15 <njsg_> one thing is saying mean things, other thing is boosting Rust without an actual reason to
13:57:48 <MattATobin> but i am gonna stop there cause it ain't good for me to continue down that line of connnversation so sorry
13:58:33 <tomman> HN will praise all things Rust for no reason, and you're being downvoted into oblivion if you dare arguing with solid reasoning
13:59:32 <MattATobin> yeah sorry for the vial negativity .. isn't even orginal vial negativity
14:00:20 <tomman> 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
14:00:57 <MattATobin> I would say they believe that like we all believe in xul.. BUT they have no passion or soul
14:01:05 <MattATobin> most of us still do
14:01:54 <MattATobin> they believe it cause they were told to
14:02:14 <MattATobin> we all do this deadend amazing shit everyone hates because we simply.. KNOW BETTER
14:02:25 <MattATobin> that is how I figure it anyway
14:02:31 <MattATobin> tomman njsg_ frg_Away
14:04:30 <MattATobin> any thoughts against or for that conclusion?
14:06:50 <MattATobin> welp enough being angry at the modern world for the moment.. I have to create alternatives lol
14:08:15 <frg_Away> 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.
14:08:59 <MattATobin> 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
14:09:27 <MattATobin> that it will outstay its welcome even for the most indoctrinated
14:09:34 <MattATobin> and we will be forced to deal with it forever
14:10:41 <MattATobin> frg_Away: MY OTHER FEAR is that mozilla will use rust to js back to rust
14:10:47 <MattATobin> conversions and bytecoad and shit
14:11:04 <MattATobin> in same insane combo as an experiment and it will never be fully removed after it fails
14:11:08 <MattATobin> that kind of shit
14:11:38 <MattATobin> rust to fe js bytecode to be ran by the js engine which is half-rust by then
14:12:52 <MattATobin> 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
14:13:41 <MattATobin> you know how mozilla loves codegen, transcoding, and bytecode shit now a days
14:13:54 <MattATobin> but like i said.. i have alternatives to fabricate
14:13:57 <MattATobin> peace