irc-logs.txt

PEMapModder: anyway, were we talking about resource loading?
+ dktapps: yeah, so i figure the only real reason we actually need the path in pluginbase is because of resource loading
+ dktapps: so if we separate that out into its own unit, then the loader can decide how resources should be accessed
+ dktapps: which makes that problem go awya
PEMapModder: I was thinking that different plugin loaders might pass different data to the plugins, e.g. PharPluginLoader and FolderPluginLoader provide path (or resource)
+ dktapps: like what?
PEMapModder: maybe there is some FtpPluginLoader that provides an FTP password, who knows
+ dktapps: hmm
+ dktapps: well
PEMapModder: or maybe an async style resource getter
PEMapModder: rather than a raw resource
PEMapModder: oh
+ dktapps: well, that's a different can of worms
PEMapModder: that's another point
PEMapModder: getResource() can't be used on other threads
+ dktapps: async loading anything blows up complexity instantly
+ dktapps: lol
+ dktapps: well
+ dktapps: lots of things can't be used on threads
+ dktapps: at least if the resource loader is a separate unit, it'll be more copyable
PEMapModder: yeah anyway the point is, any kind of ResourceLoader will still not be flexible enough
PEMapModder: because ResourceLoader is simply not a universal concept
+ dktapps: well, it solves part of the problem
+ dktapps: sell me a better way :P
PEMapModder: I don't oppose binding resources and PluginBase together
+ dktapps: well, in my mind it makes more sense to split them up
PEMapModder: if you can, of course it's great
PEMapModder: but it's not exactly important
PEMapModder: but at least separate it from PluginManager.
+ dktapps: separate what, resource loading?
PEMapModder: yeah
+ dktapps: i don't know of any ties between those two
PEMapModder: the path
PEMapModder: that's my main concern
+ dktapps: ah, yes
PEMapModder: at least, for today
PEMapModder: maybe I'll run into trouble about PluginBase tomorrow, but today I'm cleaning up PluginManager first
+ dktapps: this doesn't solve the path problem completely
+ dktapps: because of isPhar() and getFile() being used by plugins for other weird things
PEMapModder: I treat path as some "extra data" to be passed from PluginLoader to PluginBase 
+ dktapps: if we can get rid of those, we can get rid of path
+ dktapps: yeah well the path is only used for resource loading as far as i can see from a search
+ dktapps: we can have the plugin loader create the resource loader instead of having the access protocol exposed
+ dktapps: then the resource loader can do whatever it likes behind the scenes, path or not
+ dktapps: my primary concern here is that this is going to brick devtools in a few ways
+ dktapps: because it becomes problematic to build a folder plugin loader if devtools doesn't have access to getFile()
+ dktapps: since it needs to access its own source code files
+ dktapps: although i guess we could just scrap that
PEMapModder: so how is ResourceLoader sent to the PluginBase?
+ dktapps: it's not like anyone uses standalone folder loader anyway
+ dktapps: constructor
PEMapModder: and PluginManager calls the constructor?
+ dktapps: yes
+ dktapps: for now that seems to be the simplest way to do it
PEMapModder: this is the part that troubles me
PEMapModder: Actually, the constructor seems to be PluginBase-specific
+ dktapps: well, it's an improvement over the access protocol mush
+ dktapps: hm?
PEMapModder: I mean some data of it
+ dktapps: well, without the path specialization, it seems fine
PEMapModder: yeah but we just replaced path with ResourceLoader
+ dktapps: yes
PEMapModder: we still need a way to pass extra data
+ dktapps: like what?
PEMapModder: like I just said, FTP passwords, or async methods of accessing resources, etc.
+ dktapps: the FTP example you gave earlier can be dealt with by just encapsulating your FTP credentials inside the resource loader
+ dktapps: this is all a matter of the resource loader API design as I see it
PEMapModder: hmm, now it looks like I'm desperately finding reasons :P
+ dktapps: lol
PEMapModder: what about Phar metadata?
+ dktapps: what would you want phar metadata for?
PEMapModder: Phar::running()->getMetadata() doesn't look elegant
+ dktapps: well it won't work anyway
PEMapModder: e.g. when I want to check Poggit build status
+ dktapps: that returns a path :P
+ dktapps: well
PEMapModder: or check release integrity
+ dktapps: we could just have an array of general metadata passed to the constructor
+ dktapps: doesn't have to be phar specific
PEMapModder: "metadata" as in stuff only read by the plugin?
+ dktapps: although it seems like we already have metadata in the form of plugin.yml and the likes
PEMapModder: or stuff read by PluginBase?
+ dktapps: idk
+ dktapps: you brought it up :p
→ Sandertv has joined
PEMapModder: phar metadata is just one example of the data that might be used by the plugin
PEMapModder: s/the plugin/PluginBase
+ dktapps: hey snader
Sandertv: Hey dillon
PEMapModder: isn't it sandert? :thonk:
PEMapModder: I know I'm desperately finding reasons
Sandertv: Technically it's sandertTV
PEMapModder: but in addition to phar metadata, there's also phar signature, etc.
+ dktapps: phar sig is just used for integrity checking isn't it?
+ dktapps: i mean, self checking signature seems a bit redundant
+ dktapps: because if the phar has been modified, someone can just delete the signature check
PEMapModder: ik
PEMapModder: it's just an example of potential data that loader might pass to the plugin
PEMapModder: it might vary based on plugin loader
+ dktapps: just toss it in with metadata?
+ dktapps: __signature => mush
+ dktapps: i have a hard time seeing the use of self verifying signature
PEMapModder: I knew it's going this way
+ dktapps: i can buy the metadata thing
PEMapModder: so basically
+ dktapps: but not the sig thing
PEMapModder: we throw the "extra data" in an associative array
+ dktapps: we could also just require that metadata be declared in the manifest
+ dktapps: plugin.yml or whatever shit a custom thing cooks up
PEMapModder: while it should have been multiple named parameters, we pack them in an assoc array
PEMapModder: remember, metadata is just one example
PEMapModder: and nothing tells us that it's the only example
+ dktapps: what about passing some kind of PluginMetadata object
+ dktapps: hmm
PEMapModder: lol
+ dktapps: i don't like this already
+ dktapps: brb
PEMapModder: and the PluginMetadata is an empty interface or sort of stdclass?
PEMapModder: it's essentially an associative array with Java rules
PEMapModder: I find it a bit ugly
PEMapModder: actually `PluginMetadata` could just be `object` :P
+ dktapps: yeah
PEMapModder: otherwise we are doing the old CompoundTag stuff :D
PEMapModder: or Config stuff
+ dktapps: lol
+ dktapps: i was going to write something and now i don't remember what it was
+ dktapps: oh that was it
+ dktapps: for the script manifests
+ dktapps: i'm thinking about enabling the use of yaml in script manifests
+ dktapps: as in full blown yaml syntax, not just for the values like the old PM PRs
PEMapModder: the author of GrabBag suggested it back in 2015
PEMapModder: oh
+ dktapps: yeah no i don't mean that
PEMapModder: that's what you're referring to
PEMapModder: yeah got it
+ dktapps: fuck i can't type multi line here
PEMapModder: so get rid of @tags
PEMapModder: f
+ dktapps: i mean just embedding yaml directly into the header
+ dktapps: as if it was plugin.yml
+ dktapps: then we get all plugin.yml features for free
PEMapModder: so like https://gist.github.com/SOF3/f1041d83a7c6b65a628f7d04248ef6b9
+ dktapps: yep
PEMapModder: guess what, this reminds me of old PocketMine API
PEMapModder: __PocketMine Plugin__
+ dktapps: although perhaps allowing the leading *
+ dktapps: so it looks more like an actual docblock :P
+ dktapps: hmm
PEMapModder: I doubt IDEs will like it
+ dktapps: i just had an idea
+ dktapps: what if we had the manifest before the <?php tag
PEMapModder: oh, and we can't handle YAML indents
+ dktapps: hmm
PEMapModder: huh
PEMapModder: you want to use ob_start()?
+ dktapps: we could do that
PEMapModder: sounds overcomplication
PEMapModder: although there should be libraries for this purpose