Expiry field?

[st3wart]

Gui, do we support expiry for now?

[guidj]

For items? No. If we were to, each item should have an expiry field. It would be up to the Service Providers importing the data to consider whether they should be deleted or not.

Since all fields from an item are parsed, the only thing we would need to do is to standardise the name of the key. We wouldn't need to handle it here.

[st3wart]

What if it's a deal site and we know that it's not going to be valid
tomorrow. Wait for deletion?

On Tue, Aug 11, 2015 at 3:20 PM, Guilherme Dinis Jr <
notifications@github.com> wrote:

For items? No. If we were to, each item should have an expiry field. It
would be up to the Service Providers importing the data to consider whether
they should be deleted or not.

Since all fields from an item are parsed, the only thing we would need to
do is to standardise the name of the key. We wouldn't need to handle it
here.

—
Reply to this email directly or view it on GitHub
#149 (comment).

[guidj]

Tapirus does not store items, and it doesn't sync to s3. It just parses records. Once the record is parsed, every SP that consumes it can read the expiry field and delete the item.
All flat fields in an item object are parsed. It's just a question of us defining a name for the field in the documentation, and having the SPs know what to do with it. We don't need to update Tapirus for that.

[st3wart]

Ah Ok understood. So expiry field can be there right? Unix timestamp?
On 11 Aug 2015 15:42, "Guilherme Dinis Jr" notifications@github.com wrote:

Tapirus does not store items, and it doesn't sync to s3. It just parses
records. Once the record is parsed, every SP that consumes it can read the
expiry field and delete the item.
All flat fields in an item object are parsed. It's just a question of us
defining a name for the field in the documentation, and having the SPs know
what to do with it. We don't need to update Tapirus for that.

—
Reply to this email directly or view it on GitHub
#149 (comment).

[guidj]

If we define a format, we'll need to validate it.
Currently, we prefer ISO8601 format for processing, with timezone information, but we can use unix timestamp for this.
@thanyawzinmin: What's practical for the client here?

[st3wart]

I think milliseconds should be fine as javascript can do this

var milliseconds = (new Date).getTime();

On Tue, Aug 11, 2015 at 4:27 PM, Guilherme Dinis Jr <
notifications@github.com> wrote:

If we define a format, we'll need to validate it.
Currently, we prefer ISO8601 format for processing, with timezone
information, but we can use unix timestamp for this.
@thanyawzinmin https://github.com/thanyawzinmin: What's practical for
the client here?

—
Reply to this email directly or view it on GitHub
#149 (comment).

[talnetd]

Client can deal with ( almost ) anything. But prefer unix timestamp.

When should I use a timestamp ( quote from MDN ).

A Unix timestamp is interpreted the same regardless of region, and is calculated from the same point in time regardless of time zone. If you have a web application that is used over multiple timezones and you need date / time to reflect individual users' settings, use a timestamp.

[guidj]

What would be the name the field?

[st3wart]

Expiry?
On 12 Aug 2015 13:32, "Guilherme Dinis Jr" notifications@github.com wrote:

What would be the name the field?

—
Reply to this email directly or view it on GitHub
#149 (comment).