Bump to protocol version 2

[tchiotludo]

Hello,

I have done a major rewrite of your great extension.
Let me know what do you think about it.
There is an explanation is the changelog file.

Would you want to follow my idea or you disagree with my modification ?

Thanks

[tchiotludo]

@itsgoingd ; any update ? do you have take some time to look at this ?

[itsgoingd]

Hey,

Sorry for taking so long to respond, I took a quick look when you submitted the pull request, but didn't have time to think it through yet. I'm pretty sure I'll merge some of the JS app improvements, I'm not yet decided on the protocol changes though.

I'll try to have a closer look later this week.

Thanks for all your work! Though I'd wish you've contacted me with your ideas before spending so much time on something that might not get merged.

[tchiotludo]

Hello,

Thanks for your response.

I used the unpacked version of the app with my framework now, and there is some cool features with the new protocol like :

I really hope you will like it also, I'm totally addict with it.
And it allow everyone to log data & duration on any thing they want.

I've some time this month , so if you need we can work together to adjust the protocol to something that you may be more confortable with.

Thanks

[tchiotludo]

Any update ?

[itsgoingd]

Hey,

I prefer not to overly generalize the metadata format, on the contrary I'm interested in writing a more formal specification for the current metadata format. I see following as the main advantages of this approach:

• makes it easy for third parties to write applications using Clockwork metadata (eg. different types of client apps like the existing CLI client, performance analysis tools, etc.)
• allows various parts of the extension UI to be tailored for the displayed data (eg. database tab can contain functionality to run the queries, because we know we are displaying database queries not a generic table data)

That said, allowing users to extend the Clockwork UI with custom tabs is something I'm very interested in. This is a feature I actually planned from the start but never got around to implement (that's what the userData key is supposed to be used for).

So my proposed solution is - keep the current metadata format and use your proposed format and client-side code for the custom tabs under userData key.

Please let me know if you are interested in working on this further. If you are not interested (which I would totally understand as you already have a solution working for you) I might pick this up myself and implement it based on your code (with your permission and properly credited of course).

Also I'm really sorry for responding this late, I don't really have a good reason, I always end up hacking on some new project instead of managing pull requests. :)

Thanks!