12:14 <qwzybug_imac> aaronpk: I guess my use case (at least to start) isn't what you guys are best at

12:15 <qwzybug_imac> fencing and analytics aren't really what I need, my biggest problem to start is on the data side (building the system for user-generated geo content)

12:15 <qwzybug_imac> definitely makes sense to add geoloqi to that when it actually works :)

12:16 <aaronpk> so like a place to store the content along with a lat/lng?

12:16 <qwzybug_imac> also my data is going to be relatively dynamic, f'rexample, names will change

12:16 <qwzybug_imac> well, the difficulty is that the content is going to need to be relatively structured and dynamic, wiki-ish

12:16 <qwzybug_imac> so I'm going to need to have a second system in addition to geoloqi anyway

12:16 <aaronpk> we do have a pretty extensive place API, where you can create and update places and lots of meta-data http://developers.geoloqi.com/api/place/create

12:17 <aaronpk> there's an "extra" parameter where you can store any arbitrary json data

12:17 <aaronpk> it's not really meant for large documents, but I suppose it would work

12:17 <qwzybug_imac> yeah

12:17 <qwzybug_imac> I guess the app is just more of a "topic wiki plus geo" than anything else

12:18 <qwzybug_imac> and it's meant to be pretty user-editable

12:18 <qwzybug_imac> so I'd either be including credentials in the app, or writing a mirror API to send user changes to geoloqi

12:19 <aaronpk> do you already have something handling user accounts?

12:19 <qwzybug_imac> nope

12:20 <aaronpk> if you use geoloqi to do user authentication too then you could use the places API pretty well where everyone can edit the places.

12:20 <aaronpk> they aren't versioned, so I guess it woudln't make a good wiki tho

12:20 <qwzybug_imac> want it to be usable anonymously, with optional identification/facebook whatevers

12:20 <qwzybug_imac> yeah, that's the real trick I think

12:20 <aaronpk> I guess if you're looking for more of a generic document store you could look at parse.com or stackmob.com, both have the ability to associate a geo-point with records. not sure how they handle versioning of documents.

12:20 <qwzybug_imac> for such an important piece of technology, wikis are still pretty blah

12:21 <qwzybug_imac> interesting

12:22 <aaronpk> brb

12:52 <aaronpk> hello again

12:53 <qwzybug_imac> yo

15:46 <rknLA> howdy

15:46 <aaronpk> hello

15:51 <rknLA> i'm still a bit new to the api, so forgive me if this is answered elsewhere, but if i'm writing an app and want to be able to see user geodata as an admin, is that something that's possible?

15:51 <aaronpk> good question

15:51 <rknLA> also, is it possible to trigger events other than push notifications (on iOS) when a user enters a fence?

15:52 <aaronpk> you can't retrieve history through http://developers.geoloqi.com/api/location/history as an admin, unless you have a user's access token.

15:52 <aaronpk> so if you had an admin interface that could store tokens for users you could do it.

15:52 <aaronpk> the alternative is to use shared link tokens (like sharing a trip from the app) set to unlimited length, and you could store that token in the admin interface as well

15:52 <aaronpk> that'd be using http://developers.geoloqi.com/api/share/history

15:53 <rknLA> hmm.. ok, so the flow would be something like POST geoloqi:user/create_anon, and then POST my_server:user/token with the access_token provided by the create_anon call?

15:54 <aaronpk> user/create_anon will return the access token, and you can use that to make requests to location/history

15:54 <rknLA> (and PUT my_server every time it refreshes...)

15:54 <rknLA> right.

15:54 <aaronpk> and actually the tokens won't expire by default so you wouldn't have to worry about that

15:55 <rknLA> ah sweet.

15:55 <aaronpk> regarding triggering other events, yes, instead of a push notification you could notify your server at a URL and the geoloqi API will send a POST when it's triggered

15:55 <aaronpk> the POST will look like this: http://developers.geoloqi.com/api/Trigger_Callback

15:55 <rknLA> hmm.

15:56 <rknLA> so i'd have to have the trigger callback hit my server and then my server hit my app to do something else?

15:57 <aaronpk> you won't be able to do much else besides send a push if the app is in the background. for your use case will the person have the app open most of the time when the trigger will occur?

16:01 <rknLA> i'm not 100% sure it's relevant, since the trigger is going to be audio-related

16:01 <aaronpk> ah, you want to play an audio file on the phone in response to a trigger?

16:01 <aaronpk> are you talking about short-ish audio clips or audio longer than about 30 seconds?

16:02 <rknLA> yes. ;)

16:02 <rknLA> (in response to the second question)

16:02 <aaronpk> it's possible to trigger audio via a push notification (works even when the app is closed), but I believe the audio can't be very long

16:03 <rknLA> i still need to look into this a bit. the app is going to be continuously streaming audio,

16:03 <rknLA> the trigger is just going to modify the state of the stream

16:03 <aaronpk> ah, neat

16:03 <rknLA> so it's not the same as, say, a custom sound for a push notification.

16:03 <aaronpk> ok, I added a ticket to make the SDK post a notification you can listen to when a trigger is fired.

16:04 <rknLA> oh awesome.

16:04 <aaronpk> can't promise when it will be updated, but it's certainly possible for us to support that.

16:04 <rknLA> if there's anything i can do to help make that happen, definitely let me know.

16:29 <rknLA> hmm... it looks like setting up a background task that talks to a server is the only way to do that anyways..

16:30 <rknLA> linking it to a push notification requires some form of user interaction to actuate the change.