Received: by 10.213.23.12 with SMTP id p12mr214026ebb.10.1329202505243;
        Mon, 13 Feb 2012 22:55:05 -0800 (PST)
X-BeenThere: producteev-api-discuss@googlegroups.com
Received: by 10.14.28.129 with SMTP id g1ls4076319eea.2.gmail; Mon, 13 Feb
 2012 22:55:04 -0800 (PST)
Received: by 10.14.17.222 with SMTP id j70mr5386897eej.2.1329202504549;
        Mon, 13 Feb 2012 22:55:04 -0800 (PST)
Received: by 10.14.17.222 with SMTP id j70mr5386896eej.2.1329202504537;
        Mon, 13 Feb 2012 22:55:04 -0800 (PST)
Return-Path: <michael_g_muel...@hotmail.com>
Received: from blu0-omc3-s16.blu0.hotmail.com (blu0-omc3-s16.blu0.hotmail.com. [65.55.116.91])
        by gmr-mx.google.com with ESMTP id p15si13639856eep.3.2012.02.13.22.55.04;
        Mon, 13 Feb 2012 22:55:04 -0800 (PST)
Received-SPF: pass (google.com: domain of michael_g_muel...@hotmail.com designates 65.55.116.91 as permitted sender) client-ip=65.55.116.91;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of michael_g_muel...@hotmail.com designates 65.55.116.91 as permitted sender) smtp.mail=michael_g_muel...@hotmail.com
Received: from BLU197-DS3 ([65.55.116.72]) by blu0-omc3-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);
	 Mon, 13 Feb 2012 22:55:03 -0800
X-Originating-IP: [217.91.19.3]
X-Originating-Email: [michael_g_muel...@hotmail.com]
Message-ID: <BLU197-DS338368EEB59AE2500AD90A57C0@phx.gbl>
Return-Path: michael_g_muel...@hotmail.com
From: Michael Mueller <michael_g_muel...@hotmail.com>
To: "aric lasry" <lasry.a...@gmail.com>
CC: "producteev-api-discuss" <producteev-api-discuss@googlegroups.com>
References: <a16d0cda-a175-4277-9038-0f56bf8cc4ed@t24g2000yqj.googlegroups.com> <CAHko8MLQTF7awsieT0ToPbz6b5H0Uwe_iP76uDcXM8BvNMAJyQ@mail.gmail.com>
In-Reply-To: <CAHko8MLQTF7awsieT0ToPbz6b5H0Uwe_iP76uDcXM8BvNMAJyQ@mail.gmail.com>
Subject: Re: Hidden Meta Information
Date: Tue, 14 Feb 2012 07:55:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.2.3078.1025
X-MimeOLE: Produced By Microsoft MimeOLE V16.2.3078.1025
X-OriginalArrivalTime: 14 Feb 2012 06:55:03.0750 (UTC) FILETIME=[93F32E60:01CCEAE5]

thanks for your reply! I would be looking forward to your better solutions 
;-)

I see the point in not knowing which client the information belongs to but 
this could be handled by tagging the information with some unique client ID. 
The scenario that currently worries me is that I am implementing a mobile 
client and reliability of the connection is low. In this case, a request for 
creating a task might have been sent to the server but the response is lost. 
Now the client is off for a while and the user changed the task on the 
server already. Getting back online, what would I do with the pending task 
to create? I have no possibility to identify that the task on the server is 
related to the one on the client. I would like to avoid to create useless 
data or let the user solve the issue, this would be a bad UX in my opinion.

/Michael

-----Original Message----- 
From: aric lasry
Sent: Monday, February 13, 2012 10:17 PM
To: Michael
Cc: producteev-api-discuss
Subject: Re: Hidden Meta Information

Hey Michael.
This is a good point but we don't handle that and even if I already
had the need for something like that when I was using other API, I
always found another (better) solution
I don't think this is the job of the API. More over how can you be
sure that it's not another client / device that wrote these datas ?

On Mon, Feb 13, 2012 at 4:08 PM, Michael <michael_g_muel...@hotmail.com> 
wrote:
> Hi,
>
> is there a possibility to store custom meta information with an object
> which is not shown to the user?
>
> There are two reasons for doing this:
> 1. when a client calling the api has a problem with processing the
> response and could not identify the refernece ID to a created object,
> this gives a possibility to identify the object during later
> synchronisation.
> 2. custom functionality of the client could be realised without
> impacting the functionality of the web app or any other client.
>
> Thanks,
> Michael



-- 
Aric LASRY | Co-founder & Lead dev @Producteev.com | 00 (1) 646 705
1274 | New York City