A big part of putting NETMF devices out in the field is the ability to update them. If you don’t have your own server, this can prove difficult. We now offer a service for hosting your updates (2 products, 50 packages and 1meg storage free). You drag and drop your files, set the update type, versions and install path.
When coupled with the SEA (Skewworks Embedded Application) or SEL (Skewworks Embedded Library) formats it makes it easy to check if you need the new file or not. Update information can be retrieved via XML or JSON as you prefer.
@ ianlee74 - oh, I get that, I assure you. However, he’s invented his own package format(s), an api to query for them, and a service to host them (with limits), where if you used NuGet, the package format and API are standard, and the hosting is free and provided by Microsoft…
One of the things that a non-trivial deployment needs and which nuget would not give you is ‘flighting’ - that is, the ability to roll out changes to a subset of your gadget population so that you can stage deployments. Flighting can be part of a risk-limiting rollout strategy, A/B testing, beta testing, or a way to gate premium features. Nuget, to me, and aside from other not-so-fit-to-task aspects, isn’t rich enough by itself, and if you are going to have to augment it that much, then the pieces you are keeping are probably worth re-implementing so that they are fit to the task at hand rather than bent-to-fit.
@ godfroi - Let me go ahead and address some of these things for you.
The reason for the file format is to make it easier to check versions since date/time on NETMF file system still doesn’t work correctly.
You do not have to use that file format. You can upload literally any file format you want.
Using either my file format or a bootstrap like the one for SynthDOS lets you update your app on the board without reflashing
The service is there to expose items for you in the simplest possible manner to make it easy to work with on small devices. No zip, no need to parse JSON if you don’t want. You can host with me or elsewhere, you can implement your own service with the same XML/JSON format and anything can consume it.
I only have restrictions because storage still isn’t free for me either If you ha e suggestions, I’m always open to hearing them.
@ mcalsyn - I don’t know why not; you could use all sorts of built-in NuGet concepts to support flighting; tags, prerelease packages, etc.
@ andre.m - The relationship between NuGet and NETMF is exactly the same as the relationship between @ Skewworks’ package format and NETMF; i.e. there is none, unless you create it. NuGet is many things, one of which is a nickname for the “Open Packaging Conventions” (OPC) package format. This is the package format used by Office, XPS, and many other pieces of software, including NuGet: Open Packaging Conventions - Wikipedia. NuGet is also a nickname for the protocol used between the NuGet client and the NuGet server, which is actually “OData”, and which is a quite powerful protocol that allows the client to query the server in many useful ways. Finally, NuGet is also a server hosted by Microsoft which allows unlimited uploads of size-unlimited (afaik) packages.
My point here is that much has been invented by @ Skewworks, which is all well and good, but which may be redundant with systems which are already mature and in use in the wild.
Which still leaves you having to deal with file decompression. And while, yes, NETMF can handle that its slow as sin or requires RLP which isn’t always a good option.
If you don’t like it, don’t use it. If you want to give it a whirl and help improve it by offering constructive remarks, that works too.
@ Skewworks - If you’d like me to tell you that I think it’s automatically awesome that you reinvented a bunch of wheels, no thanks. If you’d like to have a discussion on the pros and cons of existing package formats and APIs, them I’m 100% game.
@ godefroi - One of us has got to be coming off wrong here and I think it’s you. No one has asked you to say anything nice, let alone that this little thing I put together for myself and decided to share was awesome.
You said you didn’t see a point, I and a couple others outlined one for you and I specifically offered you to give me constructive remarks about the system so maybe I could improve it.
Here’s a test case for you: Update an application based on date or version, as you like, using NuGet without the use of a PC or IFU.
Then go do the same thing with any of the large collection of source code I’ve provided and see what the difference is.
Is mine faster/slower? Easier/harder to work with? Is it reinventing a wheel for the sake of it? Actually try it and I’ll listen to whatever you have to say about it and improve it if I can or keep it closed to myself if no one sees a need for it.
Maybe I am coming off wrong here. I do not mean to speak ill of @ Skewworks’ ideas. I merely have enough experience with proprietary systems that I am leery of yet another package format, API, and server, especially when the hosting comes with limits. When I see that, in my brain I see the future announcement of “premium hosting” where larger applications are allowed for a fee.
@ godefroi - OK, well there’s one suggestion there"add more space". I’m not MS, I can’t bankroll endless storage on something that will lose money unless it becomes popular enough for ads to pay for it, but as long as it stays small I can probably increase the free storage.
The fee for more is $8 a month…not exactly making money on anyone that uses the “premium” version
@ godefroi - On a Hydra decompressing a 180x180 (approx 3kb file) non-transparent PNG took 77.5 seconds in regular NETMF. Zipping just the hex and loader files (no sigs) for G120 firmware results in a file 1.67mg large which would probably take about an hr at the same rate to unzip.
I would also like to point out there is no “propriety system” or API. Galaxy Updater gives you an XML or JSON file, whichever you request, with list of files, names, dates, versions and install paths. That’s it. You grab the xml/json and then download whatever files you need with a normal http request.
It’s comparable enough to make the point, mate. Is this how you approach things as a principle engineer? You could have already run half a dozen tests and validate your point or mine.
It’s not worth any more of my time talking to you. No hard feelings.
I’ve tried the ZIP method with a G400 on a 2MB text file so I could send this via email. As I recall, it took well over 30 mins to do this so I abandoned the ideal and now send smaller files every couple of hours during the day.
If you ha e suggestions, I’m always open to hearing them.