**** BEGIN LOGGING AT Wed Jun 03 02:59:59 2015 Jun 03 05:33:14 what was the database that webOS used? Jun 03 05:33:16 sqlite? Jun 03 06:11:02 db8 ? Jun 03 06:11:15 1.x used sqlite I think for some things? Jun 03 06:13:42 okay right…db8 Jun 03 06:44:07 Herrie: late pong Jun 03 06:51:28 Tofe: The orderof the XS. S. M and L are reversed on the kb size Jun 03 06:51:33 Probably something small to fix? Jun 03 06:51:45 Should go from XS to L now goes from L to XS? Jun 03 06:55:36 Herrie: but the size value is actually ok, right? Jun 03 07:06:40 Tofe: yeah label matches correct soze Jun 03 07:09:44 ok, must be my "property variant keyboardSizeChoices: Object.keys(DesignConstants.keyHeightRatio);" in UI.qml Jun 03 07:14:09 Object.keys sorts keys alphabetically !? Jun 03 07:21:00 or maybe it's the qml engine Jun 03 07:25:18 Challenge: if I have an array of objects a=[ { "name": "S", "value": 0.2 }, { "name": "L", "value": 1.5 } ] , how do I get the following array b = [ "S", "L" ] ? Jun 03 07:25:42 As a one-liner, if possible :p Jun 03 07:29:37 ah, b=a.map(function(obj) { return obj.name }) should do the trick Jun 03 07:35:26 Herrie|Veer: https://github.com/webOS-ports/webos-keyboard/pull/52 should fix it Jun 03 07:35:42 If you have a better-looking alternative, I'm in :) Jun 03 07:36:43 (Looks a bit too much like JS-spaghetti to me) Jun 03 07:37:06 It's not the prettiest but will do I guess :) Jun 03 07:37:18 I'm no JS expert :P Jun 03 07:38:46 Tofe you also have a suggestion for the kb image in XS size? Jun 03 07:39:16 Tofe: tested & merged Jun 03 07:48:57 Herrie|Veer: the kb image ? on the dismiss key you mean ? Jun 03 07:50:00 Yeah Jun 03 07:50:47 It seems I should use mipmap: true (QtQuick 2.4) but when specifying height it looks wrong still. When I remove height it's OK :s Jun 03 07:51:36 Problem is that newly created resources like the globe are 4* the size so need to specify something there to fit it inside the key :P Jun 03 07:54:09 mh Jun 03 07:56:34 Herrie|Veer: just remove the Image in the DismissKey :) It's already handled by the ActionKey Jun 03 08:00:20 Ah yeah let me PR it with mipmap: true as well then :P Jun 03 08:00:33 Will do that in a bit first some work :P Jun 03 12:16:22 wut. http://news.slashdot.org/story/15/06/02/1950234/microsoft-to-support-ssh-in-windows-and-contribute-to-openssh Jun 03 12:37:33 cool :) Jun 03 13:01:01 ka6sox, the db available to apps from webOS 1.0 was WebSQL, which is SQLite underneath. Jun 03 13:02:29 webOS 2.0 added DB8, which was implemented using BerkleyDB, and accessed via the PalmBus Jun 03 13:03:02 Starting in OpenWebOS, DB8 is implemented using LevelDB. Jun 03 13:03:16 DougReeder: do you know if it still replicates with CouchDB? Jun 03 13:03:28 It never replicated with CouchDB Jun 03 13:03:33 oh. :( Jun 03 13:03:42 saw something online that said it did....or could... Jun 03 13:03:49 It would be straightforward to implement that. Jun 03 13:03:49 also, have you seen pouchdb.com? Jun 03 13:04:05 I have; but I forget details Jun 03 13:04:30 full disclosure: I'm a CouchDB Comitter who bought a WebOS table *because* of DB8....which...as you said...wasn't quite what I thought Jun 03 13:04:34 however! :) Jun 03 13:04:43 I'd still love to see that happen...especially for OpenWebOS Jun 03 13:05:03 PouchDB is a JS implementation of most (with plugins nearly all) of CouchDB Jun 03 13:05:11 it can use LevelDB, IndexedDB, and WebSQL Jun 03 13:05:18 it supports the replication protocol Jun 03 13:05:39 is pretty lightweight and is simple to bake into everything from Firefox Add-ons to Atom-Shell to node.js servers Jun 03 13:05:41 Records in DB8 adn CouchDB are compatible Jun 03 13:06:21 does it keep a by-sequence index? Jun 03 13:07:09 _rev fields are strictly increasing, but those are for the whole DB. Jun 03 13:07:22 Would that be functionally equivalent? Jun 03 13:08:15 here's as close as we have to a spec at present http://www.replication.io/spec Jun 03 13:08:26 I think you need a by-seq for the DB *and* the document Jun 03 13:08:29 _rev on the docs Jun 03 13:08:47 so you can compare doc_a@3 with doc_b@5 Jun 03 13:08:48 etc Jun 03 13:10:33 we have a replication mailing list too, if you'd like to ask longer form questions there Jun 03 13:10:40 the number of replication-friendly endpoints is growing Jun 03 13:10:46 even Drupal has an addon that can do it :) Jun 03 13:10:51 ...or so I'm told ;) Jun 03 13:11:26 * DougReeder nods Jun 03 13:11:32 here's the link to the larger replication work in the docs http://docs.couchdb.org/en/1.6.1/replication/index.html Jun 03 13:11:47 DB8 used to have extra `_` prefixed fields that it used Jun 03 13:11:52 ...those could get in the way of replication Jun 03 13:12:03 as the other side (CouchDB or PouchDB) would have to be OK with those Jun 03 13:12:16 typically anything _* is reserved for "internal" use---for better or worse :-P Jun 03 13:12:26 beyond that, though, they seem like cousins :) Jun 03 13:12:33 * DougReeder nods Jun 03 13:12:44 k. imma shut up now ;) Jun 03 13:12:49 tnx for listening :) Jun 03 13:13:26 The pre-release descriptions of DB8 prominently mentioned CouchDB. but not later ones. Jun 03 13:14:32 yeah, what changed? Jun 03 13:15:53 I’m guessing they did not see syncing as a priority, but did see revision sets as an important feature. Jun 03 13:16:20 DougReeder: interesting hair splitting :) Jun 03 13:16:25 DougReeder: meet Kxepal Jun 03 13:16:36 Kxepal is a CouchDB replication expert :) Jun 03 13:16:38 and friend :) Jun 03 13:17:01 * DougReeder waves to kxepal Jun 03 13:17:22 hi (: Jun 03 13:17:46 So, kxepal, would there be a problem syncing records that have _id, _rev and _del fields? Jun 03 13:18:26 DougReeder: _id and _rev are fine, _del is not known by CouchDB Jun 03 13:18:32 _deleted is Jun 03 13:19:45 probably a replication service that sits between the two could handle the discrepancies in format Jun 03 13:19:51 there are actually no much specifics applied on then on replication process, they are just internal ones which eventually have to be in documents Jun 03 13:20:38 replication writes look like any other write to CouchDB (afaik), so it's just rejecting docs based on that `_` namespace requirement, yeah? Kxepal ? Jun 03 13:20:57 The underscore keys used by DB8 that I know of are "_id", "_rev", "_kind", "_sync", "_del", "_ignoreId" Jun 03 13:21:40 this is great info, DougReeder ! thanks Jun 03 13:21:47 where's the best place to look for DB8 stuff? Jun 03 13:22:24 bigbluehat: yes, those will be just rejected by CouchDB and I believe the friends too Jun 03 13:23:06 DougReeder: I see. That will require some transformation in order to convert unknown underscored fields into regular ones. Jun 03 13:23:11 that name space is configurable iirc...so you could tell CouchDB to let them in....but that's a dangerous road of "forks" I'd reckon Jun 03 13:23:31 bigbluehat: it's...complicated (: Jun 03 13:23:37 and frankly this requirements a known issue with CouchDB--imo Jun 03 13:23:51 having required in-content keys ain't so good Jun 03 13:24:20 because if we will extend number of underscore fields, we'll have to strip them away from document into some meta object Jun 03 13:24:53 DB8 API docs are at https://www.openwebosproject.org/docs/developer_reference/service_apis/db8/ Jun 03 13:25:40 Kxepal: right. or put them in an "envelope space" such as the HTTP headers or some such Jun 03 13:25:47 DougReeder: much thanks Jun 03 13:26:05 bigbluehat: HTTP headers aren't persistent - this information will be lost with the request. Jun 03 13:26:33 I think some document transform with moving special _ fields into some .meta {} object will be a solution Jun 03 13:27:15 {_id: "foo", _rev: "1-bar", ".meta": {_kind: "com.palm.sample:1"}} Jun 03 13:27:29 oh, s/_kind/kind/ (: Jun 03 13:27:42 I presume conflicting keys (or differently-named keys) could be mapped. Jun 03 13:28:13 sure Jun 03 13:28:32 _del <-> _deleted is a case Jun 03 13:28:54 Is _deleted a boolean in CouchDB? Jun 03 13:29:02 yep. Jun 03 13:29:21 That mapping should work fine, then. Jun 03 13:29:23 Kxepal: yeah. I won't keep trying to solve couchdb's _ thing here ;) Jun 03 13:29:32 ...not currently enough in my head to do that :) Jun 03 13:29:45 bigbluehat: (: Jun 03 13:29:48 DougReeder: yes Jun 03 13:30:42 but there is no need to set if false since it'll magically be stripped out of document Jun 03 13:30:45 the others, I'm assuming are ignorable as far as CouchDB is concerned...but, you could put them in a separate key-space ("db-meta" or some such) if you need them to replicate between DB8 instances Jun 03 13:31:14 Is there a list of _ fields used by CouchDB? Jun 03 13:31:41 Kxepal: we should add _deleted to http://docs.couchdb.org/en/1.6.1/json-structure.html#couchdb-document Jun 03 13:31:50 DougReeder: yep! http://docs.couchdb.org/en/1.6.1/json-structure.html Jun 03 13:32:00 but I think there's just those three at present Jun 03 13:32:02 bigbluehat: _id optional? Jun 03 13:32:13 Kxepal: if you're using POST it is :) Jun 03 13:32:34 that section does need some clean-up... Jun 03 13:32:48 When is _rev updated in CouchDB? Jun 03 13:32:53 DougReeder: _id, _rev, _deleted + read-only _conflicts, _revisions, _revs_info Jun 03 13:32:55 every write Jun 03 13:33:01 oh! forgot about all those :-P Jun 03 13:33:16 ah, and _attachments of course Jun 03 13:33:18 'cause CouchDB "adds" those...they're not really part of the document :-P Jun 03 13:33:22 I think DB8’s _rev and CouchDB’s _rev are incompatible. Jun 03 13:33:27 but _attachments is >_> Jun 03 13:33:28 blarg Jun 03 13:33:42 DougReeder: what's are DB8 revs? Jun 03 13:33:53 their ints Jun 03 13:33:55 it seems Jun 03 13:34:02 https://www.openwebosproject.org/docs/developer_reference/service_apis/db8/#.VW8Aa41FDX4 Jun 03 13:34:05 think we need strings Jun 03 13:34:19 they are incremental though (per and earlier bit with DougReeder ) Jun 03 13:34:23 I see Jun 03 13:34:35 ugh...data formats... Jun 03 13:34:44 IIRC, _rev is for the whole DB. Jun 03 13:35:02 DougReeder: assume you have rev 1339. Just turn it into "1339-UUID" and you'll be fine Jun 03 13:35:35 basically db8 has some internal int it counts up for every change. And the _rev field in single entries is the value of this int for the last time the entry changed. Jun 03 13:35:41 So, _rev can only increase for a record, but it will probably skip a bunch of numbers (other changes to DB) Jun 03 13:35:58 CouchDB will increment the numeric part sequentially, while the right side of dash is just a document hash which it seems you don't needed Jun 03 13:38:43 DougReeder: so the _rev in the document is actually the by-seq count for the whole DB? Jun 03 13:38:49 vs. the by-seq for the doc? Jun 03 13:39:08 right Jun 03 13:39:12 I think so, but I’m not familiar with that terminology Jun 03 13:39:32 DougReeder: oh...sorry by-seq == by sequence...counting up from 0 ;) Jun 03 13:39:47 * DougReeder nods Jun 03 13:39:53 in CouchDB there's a by-seq for the DB Jun 03 13:39:56 and one for every doc Jun 03 13:40:25 so if you have 2 documents with 3 revisions each you'd have a DB with a by-sequence # of 6 Jun 03 13:40:38 So, if a document changed on CouchDB, the sequence part of the _rev would not be appropriate for DB8 Jun 03 13:41:31 in that adding a third document to my little example there would be doc-c@1-{uuid}....yeah.... Jun 03 13:41:36 it doesn't contain any DB-wide information Jun 03 13:41:40 just about the doc itself Jun 03 13:41:43 ...by design Jun 03 13:42:07 as you could be using filtered replication, etc, and ending up with an intentionally "lesser" database on the other end Jun 03 13:43:13 in db8 _rev is always about the whole db. In webOS it is often used to get changes from a kind since some earlier _rev. I.e. after a contact sync you remember the highest _rev you saw and then for the next sync you get all documents with a _rev value higher than this _rev after your last sync. Jun 03 13:44:19 I think code can be wrteen to deal with the differing _rev definition. The key question is “is this a different version than I know about” Jun 03 13:46:23 what exactly is the goal of this discussion? ;) Jun 03 13:47:07 Map out a backup/sharing strategy for DB8 Jun 03 13:48:33 viz, I update something on one LuneOS device, it’s saved to DB8, then synced to a server, then my other LuneOS device syncs to the server, and I have the same data on both devices. Jun 03 13:49:36 ok.. so we don't really need to sync _rev in that use case. Jun 03 13:50:18 no, _rev is just used in the comparison during replication Jun 03 13:50:26 yes Jun 03 13:50:41 OpenWebOS is still basically node.js + UI, yeah? Jun 03 13:50:43 Yes, we need _rev to see if one side has a different version than the other. Jun 03 13:50:47 (over simplification to be sure ;) ) Jun 03 13:50:59 if so, you might dig into how pouchdb.com works in node Jun 03 13:51:04 it also uses leveldb (or can) Jun 03 13:51:12 and supports all the replication goodness of couchdb Jun 03 13:51:43 db8 is a dedicated binary. :) In fact openwebos is more UI + dbus services that are used like web services. Jun 03 13:51:49 oh Jun 03 13:51:54 I’m sure there’s a great deal that’s useful in PouchDB - but I assume it just uses CouchDB’s data structures Jun 03 13:51:55 and dbus services can be node.js, but the can also be native binaries. :) Jun 03 13:52:24 DougReeder: how do you mean? it's "just" JSON...with a few annoying _ prefix issues ;) Jun 03 13:52:44 Garfonso: cool. I think a pouchdb service would serve you well :) Jun 03 13:52:56 I presume PouchDB uses _rev in the same way CouchDB does. Jun 03 13:52:57 PouchDB (like CouchDB) is entirely schema-less Jun 03 13:53:02 nearly. Jun 03 13:53:11 the stuff after the dash is different...iirc Jun 03 13:53:17 and it's different on cloudant.com too Jun 03 13:53:29 which is a CouchDB-in-the-cloud thing Jun 03 13:53:34 and the foundation of CouchDB 2.0 Jun 03 13:53:55 the important part to the replicator is the number at the front of "1-{uuid}" Jun 03 13:54:48 in 1.x CouchDB (iirc) it is a content hash and *may* be used for replication optimization...but I'm pretty confident that's now completely optional Jun 03 13:54:59 Kxepal could say more on that (if he's still here) ;) ^^ Jun 03 13:56:56 bigbluehat: yes, rev value is N-hash where N is incremental sequential number and hash is a md5 hash from document content including previous revision. Jun 03 13:57:25 for 2.0 there is the same picture Jun 03 13:57:55 ah. good to know Jun 03 13:58:06 but that hash isn't important - it's an optimization of case when two documents may be have the exact same changes on different nodes Jun 03 13:58:39 gotcha....in which case it considers them the same--despite the #'s not matching--and carries on? Jun 03 13:58:49 vs. marking them in conflict because 2 != 3? Jun 03 13:59:26 bigbluehat: when revisions are completely identical. Jun 03 14:00:06 e.g. not only number, but hash are equals. Jun 03 14:00:37 yeah...we can move this part elsewhere ;) Jun 03 14:00:48 actually, for replication there is no need to know much about revisions. only their format is important. Jun 03 14:00:51 but I think I get it :) Jun 03 14:01:02 nice. Jun 03 14:01:24 work with them is completely transparent and each peer may decide how to use them for local routines. Jun 03 14:04:15 But a client must rember the _rev a document had when it came from the server, yes? Jun 03 14:05:11 DougReeder: it may, in order to find the right ancestry and set the right revision branch Jun 03 14:05:37 but it may not remember that and just check if there are new changes or not Jun 03 14:06:16 How does a client “check if there are new changes” without the _rev? Jun 03 14:06:27 http://docs.couchdb.org/en/latest/replication/conflicts.html#replication-and-conflict-model Jun 03 14:08:26 DougReeder: here the protocol helps. Client listens changes feed which emits events about new changes and every marked by "seq" - incremental global database id value. This value also recorded in replication checkpoints. Jun 03 14:09:04 okay I"m working on an app with my son that handles OSHW Bills of Materials and generates parts orders for various vendors. Jun 03 14:09:05 If there there is no recorded checkpoint - client starts replication from the start. If there is - since the last recorded "seq" Jun 03 14:09:18 he knows Enyo but the DB stuff was an issue. Jun 03 14:09:50 so it looks like CouchDB can do what he needs :) Jun 03 14:09:58 DougReeder: _revs are used on /_revs_diff step in order to find which exact revisions are need to replicate: http://docs.couchdb.org/en/latest/replication/protocol.html#calculate-revision-difference Jun 03 14:11:36 Thanks Guys! Jun 03 14:13:11 ka6sox: that's why we're here :) Jun 03 14:13:18 two things I love. working together. Jun 03 14:13:21 sounds like a good day ;) Jun 03 14:13:50 indeed it is. Jun 03 14:19:13 If I’m reading this correctly, a client stil need to include the old _rev when sending an update to the server. Jun 03 14:20:33 DougReeder: yes, replication client must already have any _rev in order to send it to the other side. Jun 03 14:20:46 or it starts over? Jun 03 14:21:56 Since the CouchDB _rev can’t be derived from the DB8 _rev, I think the LuneOS sync code would need to keep a separate tabel to look up the CouchDB _rev for a record. Jun 03 14:23:44 You can. Or try to convert DB8 _revs to CouchDB ones on fly. That's the option too. Jun 03 14:24:03 I’m not sure that’s possible on the fly Jun 03 14:24:08 or just add more _ fields on LuneOS side. ;) Jun 03 14:24:33 Kxepal: will that work? as the DB8 revs are DB-wide revs? Jun 03 14:24:43 Garfonso: no. not that. ;) Jun 03 14:25:11 _ All The Things!! ^_^ Jun 03 14:25:19 DougReeder: Why not? 1337 -> "1337-somehash". Jun 03 14:25:19 actually LuneOS services and libraries are doing that all the time... ;) Jun 03 14:25:30 bigbluehat: ah, that could be a problem Jun 03 14:25:33 right Jun 03 14:25:39 As long as LuneOS apps are using the merge command, adding f_ fields should work fine. Jun 03 14:28:27 if you use add with _id already set db8 throws an exception at you AFAIK. Jun 03 14:28:44 Another issue is that DB8 doesn’t allow two documents with thte same _id and different _rev. Jun 03 14:29:49 hm...so you have to find how to deal with the conflicts somehow Jun 03 14:30:57 Going back to _rev, you can’t just take a CouchDB _rev and create a DB8 record with _rev #-hash - DB8 would store it with a different _rev Jun 03 14:31:02 CouchDB allows to have documents with the same _id and different _revs and calls them conflcits. During replication, all the conflicts are being synced. Jun 03 14:32:56 I see Jun 03 14:33:08 DougReeder: I think you'll need to change logic a bit. Jun 03 14:33:53 I think a DB8 DB can’t be a replication peer of a CouchDB DB. The DB8 side could be a client. Jun 03 14:33:58 count DB8 _rev as CouchDB seq (as it global database-wide incremental unique value) and add some new _ field for CouchDB _rev thing Jun 03 14:34:56 thought, not sure if you can group such documents into the conflict tree.. Jun 03 14:37:47 so. how feasible would it be to begin using PouchDB inside LuneOS alongside DB8? Jun 03 14:38:20 seems you'd have the replication thing done, and the _kind-style filtering can be done with views (map/reduce indexes) or other query options Jun 03 14:38:22 Oh you could drop PouchDB right in. Jun 03 14:38:41 It wouldn’t be available to other apps. Jun 03 14:38:47 you could pretty easily make PouchDB act like DB8 (mostly) and get the replication "for free" Jun 03 14:38:55 and DB8 is? Jun 03 14:39:02 Yes. Jun 03 14:39:07 That’s the point. Jun 03 14:39:11 could PouchDB be setup as a node.js-based service like DB8? Jun 03 14:39:21 Sure. Jun 03 14:39:31 in which case it would be available to other apps? Jun 03 14:39:38 Yes. Jun 03 14:39:48 and that's like...what 30 minutes of work? ^_^ Jun 03 14:39:52 for a newb like myself? ;) Jun 03 14:40:24 Well, JS Services have a few wrinkles re: talking to the PalmBus. Jun 03 14:41:29 I'm not sure you can easily replace db8 with anything else... Jun 03 14:41:51 so...I don't think I'd reach for "replace Jun 03 14:41:53 " Jun 03 14:41:55 almost everything in the system depends on db8 and on it's special quirks. Jun 03 14:41:57 more like transcend ;) Jun 03 14:41:58 This would work in paralell to DB8 Jun 03 14:42:05 right Jun 03 14:42:18 with the potential that it could (eventually...if you wanted) be used in-place-of Jun 03 14:42:23 but...only if it proved it's metal Jun 03 14:43:11 hm.. and where is the benefit, then? Jun 03 14:43:28 replication story is done :) Jun 03 14:43:34 even peer-to-peer replication/sync Jun 03 14:43:48 and you'd get IBM's Cloudant service as a potential partner/endpoint option Jun 03 14:43:52 but you'd still need to replicate db8 to pouchdb, not? Jun 03 14:44:10 depends on what you're plans are Jun 03 14:44:23 you could--though it would double storage--have DB8 store copies into the replicating pouchdb Jun 03 14:44:28 and vice-versa Jun 03 14:44:51 Question: do we need to maintain db8 compatibility? Jun 03 14:44:59 oh! what if DB8 simply stored it stuff in PouchDB? Jun 03 14:45:05 ka6sox: currently, yes. Jun 03 14:45:08 What does PouchDB use for storare, when runnning in Node.js Jun 03 14:45:12 like...you'd put the current DB8 JSON inside a PouchDB "envelope" Jun 03 14:45:18 ...it'd look funny, but it'd work :) Jun 03 14:45:21 most of the code I've written for LuneOS depends on db8. ;) Jun 03 14:45:30 as _ keys can exist anywhere in the doc *below* the "root" keys Jun 03 14:45:47 DougReeder: leveldb, SQLite, memory, websql Jun 03 14:45:55 it's pretty adaptable :) Jun 03 14:46:29 oh, and http Jun 03 14:46:40 So, you’d need LevelDB also. Jun 03 14:46:44 http://pouchdb.com/api.html#create_database Jun 03 14:47:03 DougReeder: DB8 uses leveldb, yeah? Jun 03 14:47:15 I'm certain there's a way to bridge the two Jun 03 14:47:29 Yeah, but I’m not sure what’s going on underneath. Jun 03 14:47:38 or to perhaps eventually combine them...or build a replicator that "bridged" local db8 with remote couch/pouch's Jun 03 14:47:55 DougReeder: I think it's pretty simple stuff overall Jun 03 14:48:02 as there's no real "schema" required Jun 03 14:48:02 You’re talking big architecture changes. Jun 03 14:48:27 well...I've no idea on the LuneOS side...sadly Jun 03 14:48:42 back to the replicator option... Jun 03 14:48:57 if DB8 kept a per-doc by-seq somewhere (...even another _ if it came to that) Jun 03 14:49:30 and the replicator service stripped out the other _'s or "hid" them somewhere within the doc (like doc.db8-meta) Jun 03 14:49:35 then I think you'd be set Jun 03 14:49:43 that service doesn't even need to be core to db8 Jun 03 14:50:10 maybe _doc_rev? Jun 03 14:50:39 sorry...I'm entirely too excited about the idea... :) Jun 03 14:50:45 so...may apologize if I'm driving it too hard Jun 03 14:51:28 Oh, I love the idea of replication. Unfortunately, webOS went down a different path. Jun 03 14:52:46 yeah, but LuneOS doesn't have to :) Jun 03 14:52:58 "We have the technology. We can fix him" Jun 03 14:53:12 * DougReeder snorts Jun 03 14:53:18 ;) Jun 03 14:54:42 An individual app could use PouchDB and replicate. Jun 03 14:56:18 Separately, the LuneOS central DB needs to be backed up (along with a number of files) Jun 03 14:56:52 And separately from that, we’d like users to be able to sync their info from device to device. Jun 03 15:05:50 Are there CouchDB servers an ordinary user can replicate with? Jun 03 15:10:48 DougReeder: how do you mean? Jun 03 15:10:55 like does grandma run a CouchDB? Jun 03 15:10:58 :) Jun 03 15:13:25 Supposing we implement something that can replicate with CouchDB databases. What servers does it replicate with? Jun 03 15:15:36 DougReeder: cloudant, iriscouch hostings, couchbase servers, pouchdb for web and touchdb for mobile clients, soon it will be possible to replicate with drupal8. Jun 03 15:19:13 Is there software for adrress book data that uses CouchDB replication? Calendaring? Memos? To-dos? Jun 03 15:19:47 DougReeder: there are few for Android I know Jun 03 15:20:20 but not sure what's their state for now Jun 03 15:20:49 Are there services that end users can sign up for, that use CouchDB replication? Jun 03 15:20:56 DougReeder: CouchDB (et al) are schemaless, so if you put contact, calendar, etc data in it, it can be replicated :) Jun 03 15:21:09 Cloudant.com is by far the most used one Jun 03 15:21:18 Yes, I’m trying to build a use case. Jun 03 15:21:31 https://www.smileupps.com/ is the newest Jun 03 15:22:07 use case (at present) would mostly be for developers building services on top of these things probably Jun 03 15:22:12 * Kxepal afk ~2h Jun 03 15:22:31 such as any of those things you mentioned + web UI + "master-master" replication goodness Jun 03 15:22:47 like....taking on all the failed sync services of the android, ios, etc, worlds :) Jun 03 15:23:29 You’re talking about a larger problem than LuneOS is currently tackling. Jun 03 15:26:38 If such a service existed, that end users could sign up for, we would be interested in implementing the LuneOS end of it. Jun 03 15:34:02 I can envision an architecture where a PouchDB JS Service syncs data and the contacts linker reads Contacts records from PouchDB, along with DB8, to create the Person records in DB8. Jun 03 15:34:48 … but there has to be a service which distributes address book data via CouchDB, first. Jun 03 15:35:43 so...CouchDB will distribute any data you put into it :) Jun 03 15:36:15 are you meaning there should be some service (commercial or otherwise) that makes use of some specific data types for the user? Jun 03 15:36:24 like syncing and then displaying them on the web? Jun 03 15:36:28 Yes. Jun 03 15:36:44 got it. Jun 03 15:36:51 it's a cart horse problem, I'm afraid. Jun 03 15:36:55 * DougReeder nods Jun 03 15:37:11 in that, I'd be happy to display DB8-originating address book info in my app(s) Jun 03 15:37:22 ...all of which use CouchDB and/or PouchDB Jun 03 15:37:29 but I'd need it to get in there first :) Jun 03 15:37:51 the one "easy" value of the synchronization is device-to-device sync (+/- running it via a cloud host first) Jun 03 15:38:02 and "cloud" backup/storage of device data Jun 03 15:38:16 for that, the user doesn't really need to see it on the cloud side, but certainly could at a later date Jun 03 15:38:49 like...you setup sync for DB8 data to cloud CouchDB....reformat your webOS device (or setup a new one)...and then set sync up again and get back to work :) Jun 03 15:39:08 So, for a project, you could put PouchDB in a JS Service, and have it sync to a test server. Maybe running a CouchApp. Jun 03 15:40:00 yep. Jun 03 15:40:12 here's a CouchApp I'm building for viewing "any" sort of data http://github.com/bigbluehat/sprung Jun 03 15:40:35 once I know the "shape" of the DB8 generated stuff, there's no reason they could show up in sprung as types Jun 03 15:40:44 with their own editing, viewing, and listing Jun 03 15:41:22 I've also got a CMS that uses the same code...and the two of these are trending into each other: http://github.com/BigBlueHat/blueink Jun 03 15:41:43 UI's a bit different, but generally the architecture's (increasingly) the same Jun 03 15:42:27 and once I get it beyond personal itch scratching, I do hope to set it up as a "cloud" service for anyone to use--with all the offline-first storage pouchdb enables with all the replication / sync goodness CouchDB enables :) Jun 03 15:55:07 bigbluehat, the big challeng for implemening PouchDB in a JS Service is that it uses native modules, and you don’t have npm in LuneOS. Jun 03 16:02:25 sorry...was finishing up a call Jun 03 16:02:40 ah. Jun 03 16:02:46 hmm... Jun 03 16:02:52 are there plans to support npm in the future? Jun 03 16:03:12 oh. pouchdb can be bundled standalone Jun 03 16:03:16 ...not sure if that'd fix it or not Jun 03 16:04:16 also, if the replicator-service (which could be written in anything) simply moved DB8 data into remote CouchDB or PouchDB's or whatever, then those requirements could be avoided Jun 03 16:04:48 ...it's probably just a matter of calculating the distance across the various points in the canyon, and then building a bridge over the shortest one ;) Jun 03 16:18:25 It’s not clear to me that we need a general mechanism for syncing data in DB8 off-device. Jun 03 16:20:12 If you get PouchDB running as a service, separately from DB8, functionality can be built on that. Jun 03 16:21:30 DB8 is mostly used as a local cache. Jun 03 16:26:57 I think ideally we would be looking for a combination that would replace the HP/Palm profile data storage + Save/Restore functionality from legacy. Jun 03 16:30:43 Yeah, that’s another piece of the puzzle Jun 03 16:31:15 the problem I see is that as a project we should not be storing sensitive information for anyone. Jun 03 16:31:26 we should let them do like we did before Jun 03 16:31:39 let them save/restore things themselves. Jun 03 16:31:48 Right. Users need to be able to choose where their data is backed up. Jun 03 16:32:25 and its not the project's responsibility to provide that infra for actual storage..just a method to get things off the device and onto something else. Jun 03 16:33:04 Backup/restore is essentially a different functionality than syncing. Jun 03 16:34:17 syncing requires full-time thing or an app on a host machine…are either of those within the scope of what we are doing? (I'm not arguing for or against..just asking) Jun 03 16:34:42 Syncing is per-data. Jun 03 16:35:03 I guess my question is to what? Jun 03 16:35:22 As in, Contacts sync to Contacts services, such as Google contacts or Yahoo Jun 03 16:36:27 There are uses for a general device-to-device syscing service, but that’s not essential. Jun 03 16:37:32 … and a general device-to-device syscing service would actually be another service, with multiple providers. Jun 03 16:40:12 A genral device-to-device syncing service might be implemented using a PouchDB JS Service on device and a dCouchDB server. Jun 03 16:41:18 But a CouchDB server would presumably need accounts. I.e. that would be another provider, not somehting run by the webos-ports team. Jun 03 16:43:59 okay that makes more sense to me. Jun 03 16:45:04 I mean it would be good if a user can export all his data including accounts and selected app data either locally or by choice to an online service like the ones mentioned Jun 03 16:45:30 Re: backup/restore, we need to provide a mechanism for apps to backup their data. Jun 03 16:45:49 s/need/should Jun 03 16:46:55 In webOS, each app is on its own, which leads to many apps not backing up, and others using various mechanisms that the user needs to corral. Jun 03 16:46:57 I'm all for that as long as webos-ports is not the provider of that online service. ; Jun 03 16:47:02 Exactly. Jun 03 16:48:22 One possible approach is storing zip files on services like Dropbox. Jun 03 16:49:27 It would be good if each app’s WebSQL and IndexedDB files are part of those zip files. Jun 03 16:50:18 And it would be useful to able to flag which DB8 records should be backed up. Jun 03 16:50:33 DB8 records have a _sync field,but I’m not sure what it’s for. Jun 03 16:52:21 ka6Sox: Me too. Jun 03 16:54:09 DougReeder: it is exactly for that use case... Jun 03 16:55:38 in legacy you set the _sync flag to "true" for a kind and all data that belongs to that kind will be backed up to the HP/Palm servers and restored during device setup Jun 03 16:55:44 Legacy limited the use of HP/Palm profile a bit and we needed something like Save/Restore for things that couldn't be stored in the "profile" at least that's how I understood it. Jun 03 16:55:57 that is how 2.x and 3.x backup messages, notes, ... all the stuff they have in db8. Jun 03 16:56:26 Garfonso: This only works for com.palm.* or also for 3rd party? Jun 03 16:56:28 Is _sync per-kind or per-record? Jun 03 16:56:37 yeah, legacy just backed up a few specific system files and everything that is in db8. Everything else was not backed up Jun 03 16:56:43 Herrie|Veer: this works for 3rd party also Jun 03 16:56:56 _sync is per kind. At least that is how I used it. Jun 03 16:57:15 not sure if it can be different for records of the same kind. Jun 03 17:00:01 Accounts have a “sync” field (no underscore) Jun 03 17:01:17 getAccountInfo appears to return account records with a "_sync" field Jun 03 17:01:23 Just since we're not bound to the profile anymore we can be more flexible in what can be included in our LuneOS "profile" backup :P Jun 03 17:03:42 And backup it either locally to a single (encrypted if wanted) file or to an online service using Synergy connector for files? Jun 03 17:04:32 * DougReeder nods Jun 03 17:06:43 Calendars, calendar events, and calendar preferences each have a _sync field. Jun 03 17:09:35 also what I learned from my experiments with those backups is that the IDs do change (and also the _rev field) during restore... so basically they export the db8 entries as JSON and put them back in using add or something like that. That's probably why HP cloud never was used to sync stuff. Jun 03 17:10:15 also the sync field in account is handled different from the _sync field of other db8 entries. I saw that somewhere. Jun 03 17:10:33 Ah? Charming. Jun 03 17:10:56 one reason might be, that accounts lose authentication during restore... not sure. Jun 03 17:12:06 Yeah, credentials were not backed up, which is the right thing. (However irksome that is during a restore) Jun 03 17:14:02 One extension we should probably make at some point is to allow apps to request to use the credentials stored for another service, ala those “login with Facebook” buttons on websites. Jun 03 17:45:57 not sure I understand what you mean by that.. Jun 03 18:53:20 It’s a ways out from us needing to implement it. Jun 03 19:52:57 Could someone point me at some (ideally js or qml) code that calls the audio-service, please? Jun 03 19:53:46 My interpretation of audio-service/src/audioservice.cpp does not seem to be right. Jun 03 19:54:14 (I'm trying to make the Sounds settings in Settings do something, currently.) Jun 03 20:00:37 elvispre: https://github.com/webOS-ports/luna-next-cardshell/blob/e5862e9bcaa6e1d9a6675a3fac0204a5a90065ad/qml/LunaSysAPI/VolumeControl.qml Jun 03 20:02:56 nizovn: Thanks. That should get me going. Jun 03 21:06:14 elvispre: https://github.com/webOS-ports/luna-next-cardshell/blob/635c14ea915380418574ff8adcb024b92997dce6/qml/Notifications/VolumeControlAlert.qml#L36 and https://github.com/webOS-ports/luna-next-cardshell/blob/635c14ea915380418574ff8adcb024b92997dce6/qml/Notifications/VolumeControlAlert.qml#L96 Jun 03 21:07:50 AdjustVolume is in /usr/share/systemsounds and called AdjustVolume.pcm Jun 03 21:08:09 You need the playFeedback method Jun 03 21:08:14 Adn then specify the name Jun 03 22:14:36 Herrie: Thanks, I'll make a note of that too. **** ENDING LOGGING AT Thu Jun 04 02:59:58 2015