| Time |
S |
Nick |
Message |
| 00:30 |
|
|
ralphschindler joined #rest |
| 00:32 |
|
|
mezod joined #rest |
| 01:33 |
|
|
digitalsanctum joined #rest |
| 02:01 |
|
|
tieTYT2 joined #rest |
| 02:40 |
|
|
lemur joined #rest |
| 03:21 |
|
|
ewalti joined #rest |
| 06:20 |
|
|
_ollie joined #rest |
| 07:55 |
|
|
rosstuck joined #rest |
| 09:25 |
|
|
Left_Turn joined #rest |
| 09:41 |
|
|
mezod joined #rest |
| 10:56 |
|
|
_ollie joined #rest |
| 13:29 |
|
|
_ollie joined #rest |
| 14:56 |
|
|
ralphschindler joined #rest |
| 16:05 |
|
|
arbelos joined #rest |
| 16:06 |
|
arbelos |
Hello. |
| 16:11 |
|
trygvis |
hi |
| 16:16 |
|
arbelos |
I am thinking of designing an application with offline capabilities using REST and a sort of transactional log approach. |
| 16:17 |
|
|
ralphschindler joined #rest |
| 16:17 |
|
arbelos |
It seems reasonable to encapsulate state changes within nodes of a distributed system in such way, and based on some prototyping it seems to be feasible |
| 16:19 |
|
arbelos |
But my question, in case someone has experience of something similar, is how to deal with the fact that these logs can become pretty big |
| 16:19 |
|
arbelos |
i suspect |
| 16:20 |
|
arbelos |
so ideally, if only, say, two nodes are concerned. it is easy to imagine that we can sync these nodes and then purge all transactions up to the sync point |
| 16:21 |
|
arbelos |
but if many nodes are involved. transactions has to be kept in case a node is just "idle", waiting to be synced. |
| 16:22 |
|
trygvis |
how are conflicting updates handles? |
| 16:22 |
|
trygvis |
handles |
| 16:22 |
|
trygvis |
handled!" |
| 16:23 |
|
arbelos |
conflicts is definitely a problem here, but it is a different problem |
| 16:23 |
|
arbelos |
are |
| 16:23 |
|
arbelos |
but conflicts can be resolved using some policy scheme |
| 16:23 |
|
trygvis |
not really. if you don't do conflict handling you don't need anything |
| 16:23 |
|
arbelos |
need anything? could you elaborate? |
| 16:24 |
|
arbelos |
ooh.. ok i think i understand |
| 16:24 |
|
trygvis |
if you don't care about conflicts you don't need any support for resolving conflicts |
| 16:24 |
|
arbelos |
yes i see what you mean |
| 16:25 |
|
trygvis |
if a client that was offline comes online and wants to sync, you have to know if the client needs all revisions since it last was online or if just the latest version is sufficient |
| 16:25 |
|
arbelos |
ok, so my thought was to have a sync service that keeps track of the most recent "point of synchronization" for each pair of nodes |
| 16:26 |
|
arbelos |
which means that in order for two nodes to sync |
| 16:27 |
|
trygvis |
right, that can work too |
| 16:27 |
|
arbelos |
they could reverse their history up to their most recent sync point.. and then based on a policy .. re-create |
| 16:27 |
|
arbelos |
fast-forward, so to speak. hehe.. again |
| 16:27 |
|
arbelos |
of course, this is where confilicts may occur |
| 16:28 |
|
trygvis |
I guess it depends a bit on where you want to put the responsibility of synching changes |
| 16:28 |
|
arbelos |
i want the system to be flexible.. and allow different policies |
| 16:29 |
|
arbelos |
and i want as much separation as possible between the applicaition and the synchronization aspect |
| 16:30 |
|
arbelos |
so each node is acting on a RESTful interface .. making changes on local state |
| 16:30 |
|
arbelos |
a transactional log is kept |
| 16:30 |
|
arbelos |
you press "sync" |
| 16:30 |
|
arbelos |
interaction takes place with the sync service |
| 16:30 |
|
arbelos |
which keeps a log of "most recent sync point" with whatever node is being synced against |
| 16:31 |
|
arbelos |
but now... i don't want each node to keep this transactional log throughout its entire history |
| 16:31 |
|
trygvis |
for each resource you could have a version resource which you can iterate to get the changes for each revison. would be a useful case for json+patch I guess |
| 16:33 |
|
arbelos |
ok, i was not familiar with that. I'll have a look at it |
| 16:34 |
|
trygvis |
you could also serve complete states, then the client would have to find the diff itself |
| 16:34 |
|
|
ewalti joined #rest |
| 16:35 |
|
arbelos |
i am thinking, if a node is inactive for a certain amount of time and then tries to sync. Maybe they'll just have rewind to the beginning of history, there is no other way |
| 16:36 |
|
trygvis |
why wouldn't they start at the the last known point? |
| 16:37 |
|
trygvis |
anyway, this is all a bit abstract without knowing anything about the actual system you're making |
| 16:37 |
|
arbelos |
well, normally they would but i am thinking if the transaction log gets too big |
| 16:38 |
|
arbelos |
at some point resource constraints could make it necessary to introduce some limit |
| 16:39 |
|
trygvis |
then perhaps you can do both, keep X days of history/X revisions and then the client check if the server has the data it needs or not |
| 16:39 |
|
arbelos |
no it is just for an application that should run in a browser environment on various (mobile) devices, but also need some offline functionality |
| 16:40 |
|
arbelos |
so consistency is not first priority, it is more important to be able to do something useful when you are offline |
| 16:44 |
|
arbelos |
Anyway, thanks for the advice. I realize this is not really about REST design so much.. |
| 16:56 |
|
trygvis |
np. |
| 17:06 |
|
|
ralphschindler joined #rest |
| 17:10 |
|
|
_ollie joined #rest |
| 17:20 |
|
|
ewalti joined #rest |
| 17:21 |
|
|
lemur joined #rest |
| 17:24 |
|
|
ewalti_ joined #rest |
| 19:02 |
|
|
shrink0r joined #rest |
| 19:05 |
|
trygvis |
hm, with HAL, if I post an Invoice object, should the Customer be a field in the object or inside the _links object? |
| 19:05 |
|
trygvis |
and what would be idiomatic when I read the invoice again |
| 19:11 |
|
|
lemur joined #rest |
| 19:46 |
|
|
quimrstorres joined #rest |
| 19:53 |
|
|
co-arbelos joined #rest |
| 20:30 |
|
|
ewalti joined #rest |
| 20:50 |
|
|
co-arbelos joined #rest |
| 20:58 |
|
|
ralphschindler joined #rest |
| 22:54 |
|
|
quimrstorres joined #rest |
