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
<isd>
The first argument to publish is a name that you're picking for that publication. It doesn't have to be the name of a mongo collection.
<isd>
e.g. see "adminToken" in imports/server/admin-server.js
<isd>
Or "adminLog" for an example that pulls data from somewhere other than mongo entirely.
<ill_logic>
Okay. I looked at a few of the ones we used to find counterexamples.
<ill_logic>
Nope, adminToken is not a counterexample either.
<ill_logic>
shell/imports/client/setup-wizard/wizard.js:const AdminToken = new Mongo.Collection("adminToken"); // see Meteor.publish("adminToken")
<ill_logic>
Oh I see, adminLog is the counterexample
<ill_logic>
Not sure what's different about adminToken
<ill_logic>
But okay, I'll see how adminLog works. Thanks.
<isd>
I think I misunderstood what adminToken was doing at first; you're right, there is a db collection by that name.
nicoo has quit [Ping timeout: 240 seconds]
<isd>
But fwiw I don't think you need to do anything complicated here -- it should be sufficient to just add a publish that (1) checks that the subscriber is an admin, and (2) calls the SandstormDb method we defined, or returns [] if unauthorized.
<isd>
Hm, actually you probably want to do something with observeChanges(); I was thinking it would get refreshed on its own like the Tracker does on the client side, but I don't think that works for defining publishes
nicoo has joined #sandstorm
<ill_logic>
"adminLog" isn't a Mongo.Collection but it is a Meteor.Collection. From meteor's source it looks like it's just an alias though.
<ill_logic>
But it's commented as a "pseudo collection"
<ill_logic>
or referralInfo is. the other case of Meteor.Collection
<ill_logic>
I just copied the notes to the wiki in case you were gonna add anything.
<ill_logic>
(the github wiki)
<isd>
ocdtrekkie: UI for export is a bit wonky but it's there, pushed an spk.
<JacobWeisz[m]>
Awesome, I saw the notification for it. I'll have to find some time to play with it.
<isd>
I wish I were better at CSS/visual design.
<JacobWeisz[m]>
If people start using it hopefully people will contribute design fixes.
<JacobWeisz[m]>
I feel like that is a major perk to shipping it.
<isd>
Yeah I'm not thinking of this as a blocker by any means.
<isd>
Actually, everything on the MVP milestone is closed.
<isd>
I think I did -e when I published, but unless you have objections, maybe I'll bump the app version (I think I forgot to) and we can actually push it through?
<JacobWeisz[m]>
Does the -e flag actually do anything?
<JacobWeisz[m]>
Did we determine that?
<JacobWeisz[m]>
I can follow the app review process for this release, and try to test out all of the features on the milestone.
<isd>
It did print a message saying it wouldn't be published if approved.
<JacobWeisz[m]>
I just wonder if that works or how it works. I've never seen it used in practice?
<JacobWeisz[m]>
You should bump the appVersion anyways though.
<isd>
yeah. I'll do that tomorrow.
<isd>
signing off for the night.
<JacobWeisz[m]>
Night. Honestly if we ever had the code to modify the pkgdef in vagrant-spk, I'd be tempted to auto-increment appVersion by default... it's not user visible, I'd really almost rather it always go up on every pack.
frigginglorious has joined #sandstorm
frigginglorious has quit [Ping timeout: 240 seconds]
TMM has quit [Remote host closed the connection]
TMM has joined #sandstorm
frigginglorious has joined #sandstorm
Zertrin_ has joined #sandstorm
frigginglorious1 has joined #sandstorm
frigginglorious has quit [Ping timeout: 272 seconds]
frigginglorious1 is now known as frigginglorious
dustyweb has joined #sandstorm
<isd>
dustyweb: ahoy!
<isd>
ocdtrekkie: I do local spk pack locally pretty often without bumping appVersion... it feels a bit silly to have that leak in to the package metadata...
<JacobWeisz[m]>
I guess, but is it harmful? It's just a build count then, basically.
<JacobWeisz[m]>
I know the latest version of Windows 10 is major build 19041 but that has no particular key importance.
<isd>
It hurts reproducibility, which I don't like.
<JacobWeisz[m]>
That's fair. I do feel like if there was such a feature it would need to be easy to turn it on/off (Visual Studio does this), but I see a lot of "didn't increment appVersion" issues particularly from new contributors. I would like to detach the expectation that it should ever be the same between two packs in normal expectations.
<isd>
We could have the app market reject packages whose appVersion isn't > the old one.
<JacobWeisz[m]>
I think it has some ability to do that, but it might only compare against published packages.
<isd>
So maybe we should tighten that up.
<isd>
Anyway, pushed another spk
<JacobWeisz[m]>
Anecdotally, I wonder how big the app index currently is.
<JacobWeisz[m]>
Wekan has like 400 releases and each are around 100 MB. I reject a lot of intermediary packages between the ones I approve, but I don't know if the app index retains rejected packages or not.
<isd>
If it ever becomes an issue we could do some dedup magic. The data store I'm working on for our backup system might help.
<JacobWeisz[m]>
Only Kenton would know how big that grain is.
frigginglorious has quit [Read error: Connection reset by peer]
<JacobWeisz[m]>
But yeah, the only reason for the current logic is presumably to let people also base the appVersion on the appMarketingVersion if they make a mistake in submission, but I'd prefer to just always be requiring incrementation from the index.
<isd>
I don't really by the argument that appVersion should have any strong relationship to appMarketingVersion
<isd>
buy
<kentonv>
45.5GB
<isd>
That's not that bad.
frigginglorious has joined #sandstorm
<JacobWeisz[m]>
40 of that could hypothetically be Wekan releases... :P
<JacobWeisz[m]>
Though realistically I am guessing that means rejected packages do get deleted.
<kentonv>
weird, I feel like I wouldn't have written code to delete rejected packages. :)
<isd>
worth noting also there was a period of a few years when wekan was basically the only package being submitted.
<kentonv>
anyway I worry more about users' machines. Sandstorm will delete an app version once no user on the machine has that version installed anymore, but it's easy for one random user who never logs in to keep an older version pinned
* isd
looks at app index code
<isd>
probably we should include app sizes in a user's storage quota or something
<kentonv>
I dunno, if you're actually sharing the same version of an app between many users, that could make it look like people are using a lot more space than they are
<kentonv>
in fact if apps were included in user storage quota, probably most users' quota would be dominated by apps...
<isd>
accounting with shared resources is hard.
<kentonv>
I tend to lean towards updating all users on the machine to a new app version at the same time, maybe with opt-in settings to pin to an older verison.
<kentonv>
maybe the app only counts against your quota if you pin it
<isd>
I could get behind that.
<TimMc>
Divide the "cost" of the app by your share of the grains based on it? :-)
<isd>
But probably not before we start snapshotting grains automatically; users shouldn't be automatically pushed into an upgrade without a way to roll back.
<JacobWeisz[m]>
I think that's the way to go, but I think we need some more logic and options around it than we have. I'd really like to upgrade a single grain instead of all my grains. Because that'd give me the confidence to upgrade the rest.
<isd>
That occurred to me too. It seems "fair" but I wonder about UX.
<JacobWeisz[m]>
Right now I do this by having test copies of my grains on Alpha, which is fine since I'm testing apps for the market anyways, but I'd like a safer update story.
<JacobWeisz[m]>
Though if a backup system gets us to effectively the same place I am okay with that too.
<isd>
fwiw I'm not seeing any deletion logic in the app index.
<JacobWeisz[m]>
Oh, I do see -e makes a difference in my email notifications at minimum.
<JacobWeisz[m]>
SandCal is requesting review, Wekan is requesting publishing.
<isd>
I didn't do -e this time.
<JacobWeisz[m]>
I didn't get one this morning at all, I think.
<JacobWeisz[m]>
I only have appVersion 1s
<isd>
I submitted it less than an hour ago
<isd>
Should have appVersion = 2
<JacobWeisz[m]>
I don't think we got it.
<isd>
Let me try again
<isd>
Try now
<JacobWeisz[m]>
Oh, fun fact, the package you sent with -e is not available in experimental either.
<JacobWeisz[m]>
That one I got.
<JacobWeisz[m]>
In fact, the package you sent with -e isn't even served: Manually putting in the packageId into the URL won't even download it.
<JacobWeisz[m]>
I'm not sure it's possible to even review embargoed packages.
<JacobWeisz[m]>
I tested subscription and it worked with my Fastmail calendar!
<isd>
nice.
<JacobWeisz[m]>
I am good with publishing it if you are.
<isd>
+1
<TimMc>
Do you think you'll eventually have a way to push stuff from desktop calendar applications into SandCal? (Like, Thunderbird + CalDAV or something?)
<JacobWeisz[m]>
JMAP Calendars might be nice someday.
<isd>
Definitely open to CalDAV support or something.
<TimMc>
I guess if I wanted to share my calendar with someone who also uses a desktop or phone application, I could just publish to Davros... if CalDAV is general enough.
<TimMc>
Having a web calendar to go with it would be pretty cool, though.
<TimMc>
(Main use-case: Publishing calendar to spouse, maybe friends.)
<TimMc>
...I don't actually know if there are any Thunderbird extensions that can publish.
<isd>
I also have some interest in SandCal being able to subscribe to external sources. e.g. I want to be able to view google calendar events that have been shared with me without having to go sign in to Google.
<dustyweb>
hi isd
<JacobWeisz[m]>
isd, that'd be cool.
<isd>
(Other sandcal calendars are also an obvious choice...)
<isd>
bluh. my brain feels like molasses today
<JacobWeisz[m]>
That'd be a fun Powerbox example.
<JacobWeisz[m]>
Since you'd presumably want to let a user select either a SandCal grain they have access to OR an outside URL.
<isd>
Yeah. Also a good opportunity to show off the fact that you can ask for one of several interfaces: you could do one pb request for any of {caldav endpoint, other sandcal grain, google calendar api, ...}
<isd>
I really want SessionContext.request() to be implemented. having to always do the pb reqeust client-side is annoying.
<isd>
It really sucks to have this distributed object protocol and then have to completely side-step it to do this one thing.
<isd>
...I also really want a capnproto implementation that runs in the browser.
frigginglorious1 has joined #sandstorm
frigginglorious has quit [Ping timeout: 256 seconds]
frigginglorious1 is now known as frigginglorious
frigginglorious has quit [Read error: Connection reset by peer]
frigginglorious has joined #sandstorm
frigginglorious has quit [Ping timeout: 240 seconds]
<isd>
...I was so thoroughly in a rythm working that I didn't notice my battery was low and it just shut off while I was hacking...