The one thing about the protos is that they are flexible and do allow you to push things into the system easily. The thing is, from a client perspective, you could also do the same thing with JSON/etc — we don’t need a lot of performance, and $LANGUAGES already support it rather than adding in an extra dependency

The main thing I am stuck on is how to design the *storage* mechanism for the back-end. The API is pretty easy as you say — you can use protocol buffers, XML, pickles, etc

It’s the back end storage of the data in an indexable/visualize-able way and then putting together the basic viewing UI.

Hmm. More stuff to think about. I may take you up on it since I’m in Acton :)

Adrian’s app is now in the django core as a contrib app called ‘databrowse’, and that was exactly what I was thinking of.

2. proto=schema

On the .proto files I was thinking of defining a set of proto’s which are needed for storing the information. proto files just describe a schema, and there are tools which generate the reader/writer/rpc framework in multiple languages for you. Would you really want a schema-per-test? How on earth would you even begin to manage that?

the purpose of the .proto files is so that the user does not need to define the xml files (or schema), or write code for dealing with the parsing/sending/syncing of that data. You get the C++, Java, and python writing, parsing, local storage and tcp transport layers done for you. the hope being that multiple people/projects would develop backend stores for use with nose and/or other test frameworks.

Of course this would require a standardized set of proto files which nose uses. proto files are not just for data, but allow for API definitions and even calling those API’s in an RPC style.

So define a standard API set, and the standard schemas for the data used in that API, and then generate the C++, Java, and python code (and api stubs). Get that figured out and the rest is just integration.

I work in the Burlington area if you ever want to sit down at a white board.

The one thing about the protos is that they are flexible and do allow you to push things into the system easily. The thing is, from a client perspective, you could also do the same thing with JSON/etc — we don’t need a lot of performance, and $LANGUAGES already support it rather than adding in an extra dependency

The main thing I am stuck on is how to design the *storage* mechanism for the back-end. The API is pretty easy as you say — you can use protocol buffers, XML, pickles, etc

It’s the back end storage of the data in an indexable/visualize-able way and then putting together the basic viewing UI.

Hmm. More stuff to think about. I may take you up on it since I’m in Acton :)

Adrian’s app is now in the django core as a contrib app called ‘databrowse’, and that was exactly what I was thinking of.

2. proto=schema

On the .proto files I was thinking of defining a set of proto’s which are needed for storing the information. proto files just describe a schema, and there are tools which generate the reader/writer/rpc framework in multiple languages for you. Would you really want a schema-per-test? How on earth would you even begin to manage that?

the purpose of the .proto files is so that the user does not need to define the xml files (or schema), or write code for dealing with the parsing/sending/syncing of that data. You get the C++, Java, and python writing, parsing, local storage and tcp transport layers done for you. the hope being that multiple people/projects would develop backend stores for use with nose and/or other test frameworks.

Of course this would require a standardized set of proto files which nose uses. proto files are not just for data, but allow for API definitions and even calling those API’s in an RPC style.

So define a standard API set, and the standard schemas for the data used in that API, and then generate the C++, Java, and python code (and api stubs). Get that figured out and the rest is just integration.

I work in the Burlington area if you ever want to sit down at a white board.

It’s interesting — for data visualization, Andrian H. demoed an interesting dynamic visualization app pycon before last — it automatically “understood” the models and allowed highly flexible “clicking around” within the models. I can’t remember what he called it, but at the time I was wicked excited about it.

As for this — using protocol buffers is an interesting idea, I could see it using the .proto files as storage, but exposing them to end-users is equivalent to forcing them to define XML files for test cases.

Hmm, you gave me some more to think about. One of the things I thought about last night was back-ending the entire system with subversion or another SCM so you can piggy-back the versioning instead of implementing your own.

For the data communication I was thinking of using Google protocol buffers:
http://code.google.com/apis/protocolbuffers/doc…

(and using a protobuf<=>model mapper ala newforms)

The cool thing is this would not limit things to django, once the .proto files are standardized. this could allow for integration with Trac (to map things to checkins, etc) The key is to get the .proto files spec’d out and just use the django app as a proof of concept initial client and data store (or even a GAE datastore with visualization).

All this would dovetail into what is happening with the CMS and Project Management stuff going on in Pinax. Hence my request that you join the IRC discussion as you might find some people interested in implementing this stuff. ;-)

Integrate via plugins to other systems: True, some people won’t want another specialized application inside of their environ — but you keep the core of the application clean and integrate-as-needed. That’s what pinax is all about right? :)

Besides, a layer on top of an big application is not something I *personally* want. A small core implementation with plugin support/extensibility and the ability to integrate with other applications is key. If forced to make the choice though — given testopia support a JSON API and it’s something I know, I’d go with it for test case management — but not bug tracking given difficulty in customizing it without large amounts of invested time.

That also said — if I do get a chance to write something, I’ll steal some of the ideas. :)

There has also been quite a but of talk about a issue tracking/project management platform.
(We are currently using it for the development of Pinax, though I still pine for trac myself…)

I have been thinking about this myself quite a bit, but other projects keep taking up my time. I have been rather vocal about being against a full project tracking platform in Pinax. This is because whenever it is mentioned it is with words like ‘and all we need is X and we are done!’ Having written systems like this in the past these comments scare me, and I fear going down a rat hole. Thus I have wanted people to focus on other things which we desperately need (like automated testing). With that said, I would love to see this happen. I just want it done right with the proper fore though.