PROGRAMMERS! Software and databases...

[Johntodd]

I love Rod Brown's juice Calc program.

But can a programmer out there devise a "standard" for ejuice recipes? I would like to be able to download ready-made files into Rod's program and have them show up fully formatted and available in Rod's program on my computer. Any of the juice recipe websites could make the recipes available for easy importing into your personal recipe stash, and members here on ECF could very easily swap recipes by simply sending a tiny recipe file in the standard format. Even ECF itself could host a recipe file stash since each recipe would be tiny tiny tiny once collapsed into the coded file format.

This is not too big of a task, really. It's just a "form" or "field" type of thing.

Somebody please do this and open-source it to the vape community. It's one more thing to help us cement mindshare in this confused world.

Rod's program uses.xml.

I know this is doable, since I'm a programmer, too. Or I was. Last coding I did was in the late 80's. LOL!

EDIT:
OK, what I mean is a standard file-format for the recipes to be exported/imported with. Rod's program uses .xml, and I think that would be a great place to start.
1. It's a cross-platform standard, so Windows, Mac, and Linux users can read it.
2. It would be readable by future programs, ie, programs not yet written.
3. It's a pretty simple thing for a working programmer to do. (Not so simple for those of us out-of-the-loop for 30 years.)
4. It's just records keeping to a computer. The "standard" is really a construct of the human mind and then set in stone in the code.

 

[retired1]

Who do you code it for? OS X? Linux? Winderz? We have a wide range of users on ECF that use many different operating systems.

 

[Johntodd]

I know the .ical format is cross-platform. Perhaps an .xml style cross-platform format would work?

Great thing about files like this; set the format up correctly and anybody can read it.

IDK if there is a Juice cal for Mac or Linux, but a proper file-format .xml would be readable by any program written in the future.

Let me go back and edit my original post for more clarity.

 

[Dj Xy]

I think the true problem lies with the current programs, as they all use different file types, maybe if some one were to write a program that could read any of the current file types.
Or if the current programmers would put their heads together and settle on a file type to use.
Maybe someone could write a converter that could change the file type of a preexisting file.

 

[Johntodd]

That's what I'm talking about ... create a standard for juice recipes.

Then open-source it for all. There's probably a food recipe format out there that can be modified to fit our needs.

 

[Dj Xy]

Creating a standard would be ideal but the chances of getting all the program creators to agree on one would be impossible, as much as I would like to see it happen.
That's why most audio programs are able to play several different formats.
Problem is most recipe sites don't even bother making a downloadable file, they just put the recipe up.

 

[Demiurgous]

What if it were web-based? No file issues at all, find what you want.

Take it a step further, have reviews of recipes. You could also do something like "People who liked this also enjoyed . . ."

 

[Johntodd]

Good stuff.

 

[Dampmaskin]

Have a look at JSON. Here is a quick example of a JSON object that I threw together. This is a mix of 7% VG nic base with 2% PG nic base, some flavorings, and some pure PG/VG:

{

"name":"My Random Recipe"
,"author":"Dampmaskin"
,"version":"1"
,"date":"2015-02-18"
,"license":"Public Domain"
,"nicbase":[

{

"nicpercent":7
,"vgpercent":100
,"pgpercent":0
,"quota":70​

},{

"nicpercent":2
,"vgpercent":0
,"pgpercent":100
,"quota":30​

}​

]
,"flavor":[

{

"nm": "strawberry"
,"vgpercent":0
,"pgpercent":100
,"quota":5​

},{

"nm": "blueberry"
,"vgpercent":100
,"pgpercent":0
,"quota":10​

},{

"nm": "liquorice"
,"vgpercent":0
,"pgpercent":100
,"quota":1​

}​

]
,"pg":{

"quota":70​

}
,"vg":{

"quota":30​

}​

}

You'd probably want to define different ways to state quantities... percent, millilitres, drops, etc. Maybe a global property for batch size, in order to be able to convert between percentages and absolute measurements.

Maybe a "drop size" quantity too. Should it be global or for each flavor? IDK, you tell me...

My point is just that JSON is easy to work with and add to, it's relatively easy to encode and parse, and as a format it's pretty ubiquitous. If you want to make a JSON formatted standard for e-juices, feel free to use my example as a starting point, it's public domain.

The JSON specification is extremely simple. You can find it on json.org.

 

[Johntodd]

JSON might be the ticket. I've never used it before, but it is very widely used. I know Thunderbird uses it for address books and Firefox uses it for bookmarks.

Perhaps we could hash out the standard here? Come on, come all, let us create the standard in English words, and maybe some kind programmer will code it for us since he doesn't have to guess at what we want. (Much easier for him!)

I want:

1. Ingredients measured in drops, milliliters, and grams.

2. Unlimited number of ingredients.

3. Date created, date last modified, and date the recipe was last made.

4. Tasting notes.

5. In addition to Title, subtitle, class (fruit, bakery, tobacco, etc.)

6. Author or attribution.

7. Error trapping in case any of the fields are empty.

Your thoughts?

 

[Jobe84]

eJuice Me Up - Best eJuice Calculator

Simple Pretty much does everything you've mentioned. Well, almost everything.

 

[Johntodd]

That's a nice program, and I like it. But what we're trying to do here is unite all the software and websites to use one standard recipe file format.

It makes the exchange of ideas easier. The exchange of ideas is what got the Human Race to where we are, with our Air Conditioners and our medicine and our TV sets and our music and so on.

If we create the standard recipe file format, then the ejuice recipes will go flying to-and-fro with much ease; and the people will rejoice! LOL!

 

[AttyPops]

You're gonna hate this, but you need a committee. A few "major players" have to get together and then define a format. JSON or XML (JSON is kind of pushing XML out in many instances).

That format is just an IMPORT/EXPORT format.
Your other question is...where is the centralized database for the recipes? That's a different issue. It's almost as complex as a food-recipe site. You'd want web content with reviews and comments and a "download recipe" button that would give you the JSON file to import into your calculator of choice.

So now you have hosting costs too. And development.

Of course, you could do this all in 1 site, and not worry about standardizing across all software. Then you don't need import/export and don't need to convince everyone on a standard...you'd have an e-juice recipe site with a built-in calculator. Presumably supported by advertising, at least in part.

 

[Johntodd]

Ahhh ... a committee!

E-Liquid Recipes | DIY E-Juice | e cig Liquids

and

http://......................./

...are examples of what I'm talking about. They don't have the ability to send you a simple JSON of the recipes. So I do a lot of copy-and-paste and then have to re-do the formatting for my database(s).

But the standard format could solve that problem easily.

EDIT:
Censored? Sorry mods, didn't know!

 

[chrisf8657]

XML like me and Rod use would be best. It is cross platform already and specifically designed for both human and machine readability. I agree an open, standardized format would be great. The problem is getting everyone to use it. Id be on board most certainly.

I dont think breakthru will move away from flat files... Ill hold my tongue on why :-*

Sent from my Galaxy S4 on Verizon using Tapatalk

 

[Dampmaskin]

Personally I find JSON much prettier than XML, but that's of course a subjective thing. Anyway, I think the best approach may be first deciding what information should be present, and only after that deciding how to encode it.

Ok, just thinking out loud here ... So what constitutes a e-juice recipe? Maker, name, date, version, sure.

Amount and type of nic base. Should it support mixing many different nic bases? What values should be optional and what values should be required? What units should be acceptable?

A standard format must be flexible enough, so it doesn't hamstring future calculator development. Or at least it should be expandable. At the same time, the limitations imposed is exactly what makes a format.

Hmm. What about keeping it simple, and stating only the base ingredients in percents? Here's an example (in semicolon-separated text, just for the heck of it):

nic;0.6;
yummy;10;
deliciousness;10;
yuck;4.4;
vg;30;
pg;35;
water;10;

As long as the sum equals 100, the file is valid. Then it is up to the importing calculator to figure out how to assign the ingredients, decide much nicotine base you need for a 0.6 % nicotine mix of whatever size, etc.

Simpler is often better, especially when it comes to common formats.

Then we need to agree on what ingredients should be valid. The importer can then treat all "invalid" ingredients as flavors. In my example, nic, vg, pg and water could be valid (or "canon") ingredients, while the rest are treated like flavors, because the calculator doesn't recognize the names.

Just throwing it out here to see if anything sticks.

 

[chrisf8657]

One reason I would certainly advocate XML is that most programs open it, and it's widely used and an adopted standard.
If files may need to imported to other programs, it's VERY likely to support XML - I've yet to see a program I use that supports opening JSON files or it's format outside of programming languages and databases.

If it supports XML, you can map it to whatever you need to in that app - Excel, etc.

In programming you generally have to design for the least common denominator - while you as a developer may like it, the users and others who have to interact with it may not - largely because of the forementioned reason of easy import and compatibility.

A further thought would be with the standardization, an <extended> tag/area be added for custom fields a program may use itself.

 

[Johntodd]

XML sounds good.

As for recognizing ingredients by name, let's leave that out. The format should treat any entry in the ingredients section as valid. That way, if I decide I want Possum Hair in my ejuice, then I can have Possum Hair in my ejuice.

The receiving program would simply throw an alert that Possum Hair wasn't in the user's inventory.

 

[Demiurgous]

The receiving program would simply throw an alert that Possum Hair wasn't in the user's inventory.

Now that's a fancy idea. Load in flavors on hand, and query recipes you can make with those flavors.

 

[HotRod19579]

I agree with chrisf8657, XML would be the best and as he stated, XML was created as a cross platform standard.

I would make changes to use a standard format for my base format in storing recipes and ingredients so long as the standard format supported all of the elements that I currently track (weight, inventory, cost, etc). If the “standard format” didn’t track all of needed elements I would still support the standard format but it would be in an “export/import” mode.

Like chris, I am also of the belief that some others of popular calculators will not support it and will continue to use their flat file format.