kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
<CaptainCalliope>
<isd "I made a grain for the next offi"> Ah, beat me to it! Also updating the list.
<CaptainCalliope>
Pia Mancini from OpenCollective will be joining us for our meeting this tuesday. I set up a place in the notes for questions we have for her.
<CaptainCalliope>
kentonv: Does anyone actively check email accounts like community@sandstorm.io? I just ran across it in the github wiki.
<CaptainCalliope>
I'm compiling a bunch of resources about writing good documentation, how-to guides, examples, etc to inform our own documentation revamp.
_whitelogger has joined #sandstorm
<kentonv>
I don't think anyone looks at community@... it might not even work anymore. support@, contact@, and some others go directly to me.
<ocdtrekkie>
Can we just point it to you just in case?
<kentonv>
can we remove the mention of it and direct people to sandstorm-dev instead?
<kentonv>
looking at the history it appears to have been pure spam for the last couple years
<ocdtrekkie>
kentonv: Sure. I'll look at excising it from the various places it's mentioned.
<kentonv>
probably also good to remove support@, contact@, etc. if they still appear somewhere
<ocdtrekkie>
True
<michaeln3>
Is there an example somewhere of an app exposing an HTTP api to other apps, and how those other apps request it? My requests are not showing the offering grain in the modal
<michaeln3>
some side questions being: since it's a grain http offering and not a public URL, presumably the canonicalUrl could be anything as long as it's consistent, right? and secondly, the purpose of all of this being splitting document preview off of davros to decrease its size, does this setup make sense?
<isd>
Ack, the awkward thing about the canoncialUrl is that it will actually present that to a user as an option for fulfilling the request
<isd>
I feel like at some point or anothr I opened an issue along the lines of "what to do about cases where there isn't a good value for canonicalUrl"
<isd>
I'll see if I can dig that up
<michaeln3>
ah, ok
<michaeln3>
but it should theoretically show grains that offer that canonicalUrl, too?
<isd>
Per the issue, probably the right solution is to define an alternate tag type, but that's going to make integrating with the bridge awkward right now.
<michaeln3>
is there some way I can check why sandstorm isn't presenting the grain that is offering the API?
<michaeln3>
(I'm running sandstorm locally via vagrant-spk)
<isd>
How are you wrangling getting both apps running in vagrant at once?
<isd>
Are they both in dev mode, or did you pack on and then upload it...?
<michaeln3>
I packed office-previewer, then run davros vagrant-spk and upload the packed office-previewer
<isd>
We should have better tools for introspection. I'm going to open an issue.
<isd>
...at this point I'd probably dig into the sandstorm db and make sure the grains' viewInfo looks right :/
<isd>
(sandstorm mongo)
<isd>
Sanity check: you did actually create a grain for office-preview and launch it?
<michaeln3>
yes
<isd>
ok.
<michaeln3>
taking a look into the mongo instance now
<michaeln3>
it _has_ matchRequests, hard to say if they're right. I may start adding logging statements to powerbox-server.js and see where that gets me
<kentonv>
I think if canonicalUrl doesn't start with http: nor https:, then the URL won't be presented as an option to the user, but it will still be used for matching?
<kentonv>
admittedly I cannot tell if that was the intended way to use it, but the docs really seem to suggest that you don't need a canonicalUrl
biotim has joined #sandstorm
<michaeln3>
ah, so this is interesting and I may be misunderstanding how powerbox APIs work: I expected that office-previewer would expose 3 apis, and any time another grain asked for one of them, it would expose it. but it seems that requesting only one api doesn't work, I need to request all three
<michaeln3>
so in the iframe request, `query: [docQuery]` doesn't work, but `query: [docQuery, xlsQuery, pptQuery]` does
<isd>
Hm, that's odd. You original understanding matches mine.
<michaeln3>
I would have expected it to be the other way around, where a grain had to implement _all_ of the APIs in the request, but could implement additional ones
<isd>
The request is an "I would like one of these."
<isd>
But I would have expected it to display any grain that matches at least one.
<michaeln3>
ok forget what I said, the logic is correct, some sort of reloading mistake on my end :-/
<michaeln3>
now that it's working, is this the optimal workflow for what I'm trying to accomplish? which is really just moving the gigantic libreoffice dependency out of davros, with the half-idea that down the road it could preview all kinds of things via other grains
<michaeln3>
I seem to remember something where powerbox could offer to create a grain for you if you didn't already have one?
<michaeln3>
the document page in davros would have to say: "To preview, first install the [Office Previewer] app and create a new instance. Then you can [attach it]." Which may not be so bad
<isd>
How much bigger does the package get when you include libreoffice?
<isd>
Also, for a general pluggable preview feature, I might be inclined to actually use a custom capnp interface for that, rather than using something based on HTTP.
<isd>
This would let you customize the data used for matching, so you could do a powerbox request with something like tagValue = ( sourceMimeType = "application/vnd.oasis.opendocument.text" )
<isd>
which gets around the awkwardness of canonicalUrl, and also makes it trivially extensible for any mime type.
<kentonv>
The powerbox "offer" flow is supposed to someday support creating a new grain but I don't think that's been implemented
<kentonv>
and I'm not really sure if it's the right way to implement a previewer, TBH
<kentonv>
it's weird to use the powerbox to extend the _code_ of an application when you don't really intend to create a new grain.
<michaeln3>
isd: it's about 15MB without libreoffice, 125MB with libreoffice
<isd>
michaeln3: oof.
<isd>
I'd like to see a situation where apps can fulfill powerbox requests without actually creating a grain -- in this case there's not really any state it needs to keep.
<michaeln3>
right, the office-previewer has no state at all, it has a tiny UI which just lets you POST a file and the response is the converted HTML
<michaeln3>
if there was any other way to preview doc/xls/ppt files I'd certainly go that route, I myself don't particularly need it but a number of other people have expressed interest over the years
<michaeln3>
there's not a lot that can make me miss the psd format, which usually embeds a flattened jpeg
<isd>
kentonv: is the capability variant of the Action struct in package.capnp actually implemented?
<isd>
That would at least avoid the problem of having to create a grain before the functionality will work, though it means using it would create a grain that would stick around after.
<isd>
Maybe we could add a temporary field to tell sandstorm that it should delete the grain when it is shut down if there are no persistent capabilities pointing into it.
<kentonv>
I don't think that's implemented, no
<isd>
Hm, I mean, I guess you probably don't want to go through the powerbox flow every time.
<isd>
(add-ons might also be a nice thing for jupyter packaging.
<isd>
)
<CaptainCalliope>
Lots of stuff going on with Meteor these days! They just relaunched https://www.meteor.com and their cloud services product.
<CaptainCalliope>
Ok, here's a question. I want to glow up the office hours wiki page a little. As part of it I want to archive previous meeting notes more permenantly than linking to grains. Should I create wiki pages to copy paste each meeting notes grain into? Does that convention make sense?
<CaptainCalliope>
I'm asking because of the "Pages" dropdown widget on the right hand side already seems crowded and I wonder if a crowded github wiki is an antipattern.