passing a timestamp to console.timestamp()

[Markus Staab]

Hi!

I love console.timestamp() API

http://www.softwareishard.com/blog/firebug/firebug-1-8-console-timestamp/

I would like to bring it to the next level and introduce timestamps from the serverside painted into the network tab.

This would help to get a great overall picture when things happend on the server triggered by the client.

I thought about e.g. see in the firebugs timeline a mark, at which time the "routing" took place, controllers were invoked, view was rendered, etc. etc.

therefore I would send the timestamps-data within the response and then somehow use a JS api to make them appear in Firebug, like it is done with console.timestamp().

Since the events already happend and I need to mark them afterwards, I need something like console.timestamp(new Date()) or console.timestamp("date-string").

maybe it would even be a new method, so it won't affect the console.timestamp() API.

WDYT?

Thanks,

Markus

[Jan Honza Odvarko]

On Thursday, May 8, 2014 9:41:19 AM UTC+2, Markus Staab wrote:

Hi!

I love console.timestamp() API

http://www.softwareishard.com/blog/firebug/firebug-1-8-console-timestamp/

I would like to bring it to the next level and introduce timestamps from the serverside painted into the network tab.

This would help to get a great overall picture when things happend on the server triggered by the client.

Sounds great to me
 

I thought about e.g. see in the firebugs timeline a mark, at which time the "routing" took place, controllers were invoked, view was rendered, etc. etc.

One possible problem is the time synchronization between the client and the server. If it's off the event's coming from the server want match the Net pane's (client) timeline properly.
 

therefore I would send the timestamps-data within the response and then somehow use a JS api to make them appear in Firebug, like it is done with console.timestamp().

I would send the data rather through HTTP headers.
See this issue report that's related:
https://code.google.com/p/fbug/issues/detail?id=1714

But I am not sure whether you want to actually build Firebug extension (or direct Firebug patch) that allows all that automatically.
 

Since the events already happend and I need to mark them afterwards, I need something like console.timestamp(new Date()) or console.timestamp("date-string").

maybe it would even be a new method, so it won't affect the console.timestamp() API.

It could be enough to use internal API, in case you want to build a Firebug feature.

Otherwise we could teach the console.timeStamp to use new Date argument... (and a label)

Honza
 

WDYT?

Thanks,

Markus

[Markus Staab]

One possible problem is the time synchronization between the client and the server. If it's off the event's coming from the server want match the Net pane's (client) timeline properly.

thats right. I thougt about using timestamps relative to the server-request start time and let the browser calculate the exact point in time using performance.timing API.

The browsers time is not available at the server, right?

 

I would send the data rather through HTTP headers.

See this issue report that's related:
https://code.google.com/p/fbug/issues/detail?id=1714

But I am not sure whether you want to actually build Firebug extension (or direct Firebug patch) that allows all that automatically.

I would like to built such thing without a Firebug extension. Also thought about using http headers for it, but this would only solve my problem using server-side things.

I think there are even more use-cases which could be solved if there were a JS api doing stuff like that.

 

It could be enough to use internal API, in case you want to build a Firebug feature.

Otherwise we could teach the console.timeStamp to use new Date argument... (and a label)

exactly what I would like to have ;-).

Thanks,

Markus

[Jan Honza Odvarko]

On Thursday, May 8, 2014 11:10:22 AM UTC+2, Markus Staab wrote:

One possible problem is the time synchronization between the client and the server. If it's off the event's coming from the server want match the Net pane's (client) timeline properly.

thats right. I thougt about using timestamps relative to the server-request start time and let the browser calculate the exact point in time using performance.timing API.

The browsers time is not available at the server, right?

Right
 

 

I would send the data rather through HTTP headers.

See this issue report that's related:
https://code.google.com/p/fbug/issues/detail?id=1714

But I am not sure whether you want to actually build Firebug extension (or direct Firebug patch) that allows all that automatically.

I would like to built such thing without a Firebug extension. Also thought about using http headers for it, but this would only solve my problem using server-side things.

I think there are even more use-cases which could be solved if there were a JS api doing stuff like that.

I see
 

 

It could be enough to use internal API, in case you want to build a Firebug feature.

Otherwise we could teach the console.timeStamp to use new Date argument... (and a label)

exactly what I would like to have ;-).

I think that the best next step would be creating an issue report  + a test case

I can suggest a patch related to the console.timeStamp API

Honza



 

Thanks,

Markus

[Markus Staab]

here we go https://code.google.com/p/fbug/issues/detail?id=7452

[Markus Staab]

Hi Honza!

 

I can suggest a patch related to the console.timeStamp API

please cross post the bugticket from mozilla regarding to a possible api change/addition

Thanks,

Markus

[Jan Honza Odvarko]

There is no existing bugzilla report.

What I have in mind is:

1) Let's first have a test case (+ the server side that sends some timing info)
2) Modify Firebug's console.timeStamp() and see how the entire scenario works
3) If all work well, talk to other devtoolers and suggest the console API change

Honza

Thanks,

Markus

[Markus Staab]

I created a testcase in the linked issue.

In case we add this new signature for console.timeStamp() we don't need a end to end test, do we?

--
You received this message because you are subscribed to a topic in the Google Groups "Firebug" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebug/5hEUeaKYzNc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebug+u...@googlegroups.com.
To post to this group, send email to fir...@googlegroups.com.
Visit this group at http://groups.google.com/group/firebug.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebug/3ee70619-4e57-4639-998b-c5a3f50dc459%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jan Honza Odvarko]

On Thursday, May 8, 2014 4:23:12 PM UTC+2, Markus Staab wrote:

I created a testcase in the linked issue.

In case we add this new signature for console.timeStamp() we don't need a end to end test, do we?

What do you mean by end-to-end test?

 In any case we need to ensure backward compatibility (so, e.g. we can check the type of the argument passed in and if it's a Date() then execute the new logic)

Honza
 

2014-05-08 14:56 GMT+02:00 Jan Honza Odvarko <odv...@gmail.com>:

On Thursday, May 8, 2014 12:42:04 PM UTC+2, Markus Staab wrote:

Hi Honza!

 

I can suggest a patch related to the console.timeStamp API

please cross post the bugticket from mozilla regarding to a possible api change/addition

There is no existing bugzilla report.

What I have in mind is:

1) Let's first have a test case (+ the server side that sends some timing info)
2) Modify Firebug's console.timeStamp() and see how the entire scenario works
3) If all work well, talk to other devtoolers and suggest the console API change

Honza

Thanks,

Markus

--
You received this message because you are subscribed to a topic in the Google Groups "Firebug" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebug/5hEUeaKYzNc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to firebug+unsubscribe@googlegroups.com.

To post to this group, send email to fir...@googlegroups.com.
Visit this group at http://groups.google.com/group/firebug.

[Markus Staab]

with end-to-end I mean a testcase where also the server-side is implemented.

> In any case we need to ensure backward compatibility (so, e.g. we can check the type of the argument passed in and if it's a Date() then execute the new logic)

we will need a label nevertheless, so we should introduce a second optional date parameter.. no need for type-checking of the arguments.

Markus

To unsubscribe from this group and all its topics, send an email to firebug+u...@googlegroups.com.

To post to this group, send email to fir...@googlegroups.com.
Visit this group at http://groups.google.com/group/firebug.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebug/16e7dc4f-9995-4d14-82d8-bb5d56c92949%40googlegroups.com.

[Jan Honza Odvarko]

On Thursday, May 8, 2014 5:01:36 PM UTC+2, Markus Staab wrote:

with end-to-end I mean a testcase where also the server-side is implemented.

Yep, I believe this would be useful. Note that Firebug test use PHP for the server side logic.
 

> In any case we need to ensure backward compatibility (so, e.g. we can check the type of the argument passed in and if it's a Date() then execute the new logic)

we will need a label nevertheless, so we should introduce a second optional date parameter.. no need for type-checking of the arguments.

OK, make sense, let's do it this way.

Honza
 

Markus

[Markus Staab]

Hi Honza,

added a sample code how things could work from a api-consumer perspective.

https://code.google.com/p/fbug/issues/detail?id=7452

Should we move the discussion into the issue, or do you think its worth also using the maillinglist?

Thanks,

Markus

Markus

To unsubscribe from this group and all its topics, send an email to firebug+u...@googlegroups.com.

To post to this group, send email to fir...@googlegroups.com.
Visit this group at http://groups.google.com/group/firebug.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebug/3ee70619-4e57-4639-998b-c5a3f50dc459%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Firebug" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebug/5hEUeaKYzNc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to firebug+u...@googlegroups.com.

To post to this group, send email to fir...@googlegroups.com.
Visit this group at http://groups.google.com/group/firebug.

[Christ van Willegen]

On Tue, May 13, 2014 at 12:43 PM, Markus Staab <maggus...@gmail.com> wrote:
> Hi Honza,
>
> added a sample code how things could work from a api-consumer perspective.
> https://code.google.com/p/fbug/issues/detail?id=7452
>
> Should we move the discussion into the issue, or do you think its worth also
> using the maillinglist?

It's weird to put this in the reply... This way, you can't measure the
timing of your generated HTML, CSS, JS, but only JSON replies from the
server. AND you need to make sure that this doesn't influence your JS
application.

I think it's better to put this info in the reply headers.

Christ van Willegen
--
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

[Jan Honza Odvarko]

On Tuesday, May 13, 2014 12:54:24 PM UTC+2, Christ van Willegen wrote:

On Tue, May 13, 2014 at 12:43 PM, Markus Staab <maggus...@gmail.com> wrote:
> Hi Honza,
>
> added a sample code how things could work from a api-consumer perspective.
> https://code.google.com/p/fbug/issues/detail?id=7452
>
> Should we move the discussion into the issue, or do you think its worth also
> using the maillinglist?

If we expect feedback from the community, we should discuss here, otherwise we should use the issue report.

 

It's weird to put this in the reply... This way, you can't measure the
timing of your generated HTML, CSS, JS, but only JSON replies from the
server. AND you need to make sure that this doesn't influence your JS
application.

I think it's better to put this info in the reply headers.

Yeah, it would be better..
 
Markus, what do you think?

Honza

[Markus Staab]

Hi Guys!

Am Dienstag, 13. Mai 2014 12:54:24 UTC+2 schrieb Christ van Willegen:

On Tue, May 13, 2014 at 12:43 PM, Markus Staab <maggus...@gmail.com> wrote:
> Hi Honza,
>
> added a sample code how things could work from a api-consumer perspective.
> https://code.google.com/p/fbug/issues/detail?id=7452
>
> Should we move the discussion into the issue, or do you think its worth also
> using the maillinglist?

It's weird to put this in the reply... This way, you can't measure the
timing of your generated HTML, CSS, JS, but only JSON replies from the
server. AND you need to make sure that this doesn't influence your JS
application.

I think it's better to put this info in the reply headers.

the posted snippet is just sample code. One could use http headers, json, cookies or even async events using websockets.

the only thing which the browser needs to support is console.timeStamp(<label>, <date>);

everything else needs to be implemented by the api consumer.

Is it more clear now?

Thanks for your feedback,

Markus