Looking for member of dev team to answer a few xml questions.

bolwire

New member
Im looking for someone on the dev team who is involved with the xml files that could answer a few questions.
I am experienced in HTML, ASP, Visual Basic, C, Perl, MySQL, MSSQL.

My specialty has always been providing that off-beat solution that is useful in some way, but not really worth the time and effort of a dev team. Mainly reading saved data, and displaying that data in a report or some other useful manner to an end user.

Im not really sure how I may be able to do that in this case yet, but Ill list a few of my basic questions here, and if I get a reply that is understandable that will help me with a direction to travel in.

Question 1. .tim xml files

When I open a .tim file in notepad, I see the following line, the computer I use V3 on is not connected to the internet, so what is the purpose of this line in that file ?

<TimedSequenceData xmlns:a="http://www.w3.org/2001/XMLSchema" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/VixenModules.Sequence.Timed">

Question 2. the SystemConfig.xml file

In the controller section, the following line for Renard CH1. Where does the string for the id value come from? Is this string the same for everyone using V3? Will the id for CH1 always be the same ?

<Output name="Renard-1" id="50467fe1-6efa-4865-bb3e-e15e8461c342" />

If someone has the time to answer these questions for me, I would be very thankful. I hope I have not offended anyone, as this is DIYC community and digging around and playing with new things is what got most of us here to start with.

Thank you for your time,
James
 
Last edited:
Hi James,

If you'd like to get on the development mailing list, check out this thread: http://doityourselfchristmas.com/fo...o-Module-Development-and-the-Dev-mailing-list You'll get quicker and more detailed replies -- I don't check the forum as often as I should. :)

To answer your questions:

1) The XML is serialized using a DataContractSerializer. I believe that's what is putting that line in there (as well as a bunch of the other schema stuff). We're actually going to change the way the files are stored next year, since there's a lot of problems with the current system.

2) the IDs are randomly generated GUIDs used to identify that particular output instance on that controller. They're random, and will not be the same across installs. This has both benefits and drawbacks, depending on what you're trying to do. :)

Hope that helps. If you're trying to achieve something in particular, let us know.

Cheers,
Michael
 
Thank you for the reply. I am a member of the group already, but having been a part of a few dev teams in the past, I didn't want to be labeled as "that guy."

I guess at this point my primary goal is to just be able to intake the data from the xml and make sense of it. No real reason yet.

That last program I wrote would intake the .dat file from a popular Ham Repeater configuration software and output a .html file, the config program was great, however it left users writting their info out by hand. I made a few plugins for it that would also keep the on board clock up to date via rs232 communication, as well as retrieve weather information and store it as spoken text in the controller.

So thats just kind of what I do...

I would love to be a part of the dev team in some way, but you guys are way ahead of me. I can not even figure out how to get the source at this point. Not familiar with Git all that much.

Thank you,
James
 
Hi James,

No worries, great to hear. I didn't realize you were already on the group -- feel free to ask questions, no one will mind, and if there's something specific (eg. a Git crash course) then people can point you at older posts or web pages to help get you started. :)

Cheers,
Michael
 
Hi Michael,

I was getting ready to edit my post when I saw that you had replied already. Then I thought, wow your up early, then I saw your on the other side of the world... The last few nights I have only been able to sleep from about 10pm to 1am. Pretty rough as I work 12 hour rotating shift from 7am to 7 pm. But, I managed to do it again tonight. So Here I am.

The Tortise git had me confused. I trashed it and grabbed git, and Im up and going, just waiting on VS to install, my 2010 was too old. Im still using Vista, as I dislike the direction microsoft soft has gone with windows, especially 8. But that is another story.

Ill have alook around at things. After this post Ill use the group with any questions related to the dev portion. If someone wants to contribute something how ever, what is the conventional method of bringing the proposed items up to the team.

I know everyone is trying to get it as stable as possible for the upcoming year, but Ive made a few suggestions, if I am able to get those working, as they are LOW LOW LOW on the priority list, do I need to discuss that with someone first ? I am not looking to jump in and change a bunch of stuff by any means at all. And I am thankful for the openness and acceptance of others to be able to even look into this project.


Ive had rouge editors in the past and it can be a nightmare, but Im new to github and it seems like it handles alot of things as far are accepting or rejecting comits.

Thank you once again for your time,
James
 
Hi James,

just a quick reply inline:

The Tortise git had me confused. I trashed it and grabbed git, and Im up and going, just waiting on VS to install, my 2010 was too old. Im still using Vista, as I dislike the direction microsoft soft has gone with windows, especially 8. But that is another story.

No worries. I personally like tortoiseGit -- provides a nice frontend to visualize the different branches, repositories, etc. -- but whatever you want to use should work. :)

I found this handy to learn Git: http://blog.anvard.org/conversational-git/

Also, there's been reports that the express (ie. free) version of VS 2013 works with Vixen 3. I haven't tried it myself though.


Ill have alook around at things. After this post Ill use the group with any questions related to the dev portion. If someone wants to contribute something how ever, what is the conventional method of bringing the proposed items up to the team.

Well, the good thing about Git is that everyone has their own copy of the code (their own repository) -- so you can make whatever changes you want, make them public for us to see (ie. "push" it to github, where it resides in your copy of the code), and then I can review it, make comments, merge it into mine, reject it, etc.

So sometimes some things have started as someone playing around in an area, testing out an idea, and then it snowballs until it's done.... then they push it and everyone likes it and I merge it.

Sometimes, it comes out of a discussion -- someone asks "has anyone tried X?", and then we talk about it, and someone else starts work on it. So there's no real defined process.


I know everyone is trying to get it as stable as possible for the upcoming year, but Ive made a few suggestions, if I am able to get those working, as they are LOW LOW LOW on the priority list, do I need to discuss that with someone first ? I am not looking to jump in and change a bunch of stuff by any means at all. And I am thankful for the openness and acceptance of others to be able to even look into this project.

As I explained above, you can have your own copy and play with that, so it won't affect anything else. However, sometimes it's worth discussing with the group or myself, if only to bounce ideas around, or sometimes because we've already discussed it and have decided to implement it in a different way next year, etc. But that doesn't mean you have to -- you can start playing around how you want, it just means you run the risk of having your work rejected or duplicating effort if it doesn't 'fit in' with the rest of the stuff we're doing. :)

Cheers,
Michael
 
1) The XML is serialized using a DataContractSerializer. I believe that's what is putting that line in there (as well as a bunch of the other schema stuff). We're actually going to change the way the files are stored next year, since there's a lot of problems with the current system.
Michael

You say that you are changing the way that files are stored next year... I have been wondering for a while why the development team went with XML in the first place. I would assume this is because this is the way it was done in Vixen2 and many other sequencing software products. As you know, as pixels become cheaper and more popular, and channel counts grow exponentially, many sequencing software products can no longer keep up. One of the reasons I believe is due to the inefficiencies of XML. XML data cannot be indexed so reading parts of it can be very slow, and reading all of it into memory can be very resource intensive, especially when dealing with the large amounts of data required with pixel counts in the thousands or tens of thousands. Has there been any though of using a database such as SQL Server Express or mySQL?

I am an IT director with roots in Database Administration and Programming and have worked with many data driven applications. Data in Databases can be indexed and revival can be very fast without the need to keep everything in memory. They use b-trees and other very efficient data structures to store data. A properly designed database can have smokin' good performance. What is more, do things such as apply complicated effects to a range of elements through the use of a single Update query.

I cannot think of many applications that could benefit from the advantages of a database to the extent that a sequencing and scheduling program such as Vixen could.

...any chance that this new way of storing files might involve using a database?

I have thought of mentioning this many times but I realize the monumental task that would be involved in reprogramming Vixen to move from XML to a database so I have been holding my tongue. But, since you mentioned that you are changing the way files are stored, I was curious.

Thanks,

Tom
 
One of the ideas we're currently exploring is using a noSql data store. I'm not the best guy to talk to on the top, but as I understand, its a particularly good choice for our type of data.

I believe HLS uses one of the SQL variants for its data store.


-- Jon Chuchla --

Sent from my iPad using Tapatalk
 
Interesting. I can see it from the standpoint of having a more flexible data data structure. I can attest to the difficulties of changing the data structure down the road when using a traditional RDBMS.

There are pros and cons either way I suppose. But anything is better than XML for this type of data.

Any idea which one? There are many of them and some are highly specialized.


Sent from my iPhone using Tapatalk
 
You say that you are changing the way that files are stored next year... I have been wondering for a while why the development team went with XML in the first place. I would assume this is because this is the way it was done in Vixen2 and many other sequencing software products

Actually, the reason it was using XML was because it was quick, easy and convenient for development -- we use DataContractSerializers to serialize out the data and read it in, and it requires almost _no_ effort or manual intervention in the serialization process. When KC was first developing it, he went with that as it was something he was playing with at the time.

One extra benefit was that it was human-readable, which was a bug plus in previous versions -- ie. people liked to tinker with the V2 data file. (I don't see this as a big benefit, and have no motivation to keep it human readable for that reason.)

However, over time it's become obvious that it's not an ideal format. Mainly due to size -- the DCS and XML can take hundreds of bytes to wrap a single bit of information that could be stored in a handful -- and also because it's fragile between versions. It's great if nothing changes in the object, but if we want to update versions, controllers, effects., etc. and want to add new data or change values of a data, we're looking at trouble.

So, we're looking to change how data is persisted (sequences, configs, etc.) This part of data storage (which is currently XML) doesn't actually have any bearing on performance.

Separately to that, we're also looking at improving how data is rendered and stored in memory. This doesn't use XML at all, and is what is the cause of the memory bloat, and the performance issues in some cases.

So, we're looking at a bunch of options at the moment. Thanks for your comments and suggestions; that's some of the stuff we're looking into and discussing. :)

Cheers,
Michael
 
Back
Top