Next version: Numbering scheme and possible more often updated dongles

[muellerph]

Hello Chris,

currently we have from time to time a new release. No pressure, it will just come when it is ready.

With each version, we normally have changes on the server side of VOMP which means for each release the client needs to be in sync with the server.

Wouldn't it make sense to have more releases on the client side with changes that don't depend on the server or protocol updates?

Like my patch for the scrollable summary, I assume a lot of persons would like to have them in their dongle but for the moment they would need to wait till the next complete release is done. This may take ... till it's ready.

I (or maybe others) would be willing to update the last release with the patches/changes which are:
A) Not depending on server/protocol changes
B) Included in the current cvs version
C) Non intrusive

So bugfixes, translation updates and "known to work" backports would be allowed.

If you (and the other) would agree to this, I would also change the naming scheme.
So 0.x.y would mean:
x: Server/protocol release number
y: client release number

Would this make sense to you?

[avvdr]

Hello Chris & all,
what would you think of introducing some versioning and compatibility handling at the interface?
I started now some work that I needed for the mediaplayer - basically there are some simple patterns that would allow for easy compatibility handling:
1. have some data holders (classes with no reference to anything except defines.h)  that are used on both sides
2. make them serializable with some version handling included (I'm just done with the necessary classes I use for the mediaplayer)
3. being a bit carefully when adding new attributes to the classes (just ADDING, not changing semantics)
With this simple approach we could easily maintain compatibility at the interface that would allow us to be more flexible. I guess a lot of people would like it to be able to run e.g. the newest dongle against an older server plugin (OK some functions will not be available - but it works).
At the end we could also add some protocol version that could be send from the server to the client (and vice versa)...
Just to illustrate my ideas I add here some files that I used now to have serializable data holders with versioning for the media player (they will become part of the next media player patches).
serialize.*
  - base classes for ser/deser (just adding 6 bytes overhead for a class - 2Bytes version, 4bytes length)
  - SerializableList - a simple container class to construct VDR-commands (see vdrcommand.h) without explicitly implementing serialize/deserialize
media.*
- examples how I use this for the media player

At the end the above patterns would also ease the testing of new protocol features (I'm just thinking of creating a small testing framework to test serialize/deserialize + compatibility) - this way we can implement and test the data holders independent of everything else - and there is no need to "frickle" with protocol details.

What do you think of such an approach?

Regards
Andreas

[Chris]

Right, hibernation over. Vomp time.

Andreas: I have had a quick look at the serialize stuff, but I think I will need to look at it some more later. It looks a lot like some of the latest networking code already in cvs for dynamically making packets, so we will have to work out which way to go with these things.

Philipp: Your post makes sense, I had assumed this kind of thing was going on already over at vdr portal

Philipp and everyone else:

So, I think we should be making more interesting use of the web site. I want to have articles on there which describe how to get each part vomp working - this leans towards a wiki. I would also like to have other trusted users be able to write on the web site, e.g. Marten for describing the Windows version - this also leans towards a wiki. It would be good to have trusted users such as yourself Philipp able to post dongles to the site as you have pointed out - this doesn't lean towards a wiki. What does it suggest? It would be good to allow patch writers to put patches on the web site in the same way.

The forum is good, it allows for user-user support - that will stay. The current web site content is sparse and could be replaced with another system. A wiki springs to mind for the articles but isn't ideal for people sharing a set of files. I don't know what software could do the job of allowing people to have their own areas with patch sets etc, any ideas?

Or has anyone come across some other web software that will one (or preferably more) of these ideas?

[MartenR]

Maybe we can make like the people from mvpmc, they organize their code using git.
A lot of the developer have their own branch for playing around with their code and a main branch for the release to which the improvements, after they are tested. Maybe this can help to organize the stuff.

For the website a content management system maybe a possible option like typo3.

Marten

[avvdr]

Hi Chris,

Andreas: I have had a quick look at the serialize stuff, but I think I will need to look at it some more later. It looks a lot like some of the latest networking code already in cvs for dynamically making packets, so we will have to work out which way to go with these things.

I had the following major intentions:
1. easy use
The use of some data holders on both sides (client+server) makes it quite simple and straightforward to implement new protocol features or extend existing ones. If we would go this way, I have some ideas about a small testing framework that will easily allow for testing those data holders separately (by writing the serialized data to files and reading it again - so we could even test version compatibility). You will get nearly completely free of any protocol issues that are typically hard to debug.
2. version compatibility
With the proposal you can easily get forward and backward compatibility by following some simple pattern (i.e. only add elements, always add at the end in serialize). This way you can run a server x.1 against a client x.5 and can easily handle it on both sides.
3. Not too many classes
By providing the SerializableList for simple messages you can create protocol messages on the fly without really writing the serialization/ deserialization (by the minor drawback of the dynamically created list).
I already saw that you did something in the protocol (so obviously the serialize buffers are similar) - but (as far as I understood) there is no version/length encoding of each element - that is the prerequisite for such compatibility stuff (at least if you would like to have forward comp. too...

I used the code now within the commands for the mediaplayer with the newest patches...

Regards
Andreas

[muellerph]

Remark to the protocol topic: Maybe better to have a separate thread.

Let me give my comments/ideas:
- Git:
Yes I assume git would fit the development style better. Even that I'm comming from KDE and am used to a central code system, I understand the difference here. I have no experience though with git. Also I don't know where the main git repository should reside to have online access.

- Wiki:
Yes, Chris is currently the only one able to maintain the webpages and Chris time is very limited. So I would vote yes for a wiki. Better than plain HTML pages and very common nowadays.

- Dongles:
Why not hold them on SF? Here we have the possibility to provide different dongles with the possibility to limit upload access already?
The file can then be linked from a wiki.

- Patches:
This is difficult.
Patches should reside when accepted in a repository. How to do this with git I don't know yet (for e.g. an updated dongle), but with CVS it should be in the original tree (BRANCH, for sure not MAIN).
Storing patches maybe on SF, but also a CMS may help here for having the patch collection organized.
I haven't seen a project yet who manages/organizes patches to get a clue how to do it, do you know one?