muffin stuff#2 (webstart cookies)

[oNyx]

http://kaioa.com/src/tools/MuffinTest.jnlp
http://kaioa.com/src/tools/MuffinTest_src.zip

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17

public class Muffin Constructors: public Muffin(String muffinName) throws MuffinException public Muffin(URL muffinURL) throws MuffinException Methods: private static void init() throws MuffinException public String toString() public static String[] getNames() throws MuffinException public static String[] getNames(URL url) throws MuffinException public boolean exists() throws MuffinException //doesnt work :P public int getTag() throws MuffinException public void setTag(int tag) throws MuffinException public void delete() throws MuffinException public InputStream getInputStream() throws MuffinException public OutputStream getOutputStream()

It's more (re)usable and the demo application is also more interesting now. You can load, save and delete muffins.

Tell me what you think'n'stuff.

Btw the source is comment free - it's ment to be some kind of draft.

[kevglass]

Just to prove I read what you wrote

What happens if I call delete() then call getOutputStream()?

I take it the tags are the ones that I defined within the JNLP lib?

I'm really starting to like that style of using static methods on a class to get the collection, its really intuitive, at least for me

Looking smooth,

Kev

[oNyx]

>What happens if I call delete() then call getOutputStream()?

Nothing special.

The (inner class) MuffinOutputStream deletes the muffin anyways (tries to - actually [since there won't be a muffin in first place]), then creates the muffin and then writes (in the close() method, because we don't know the final size before).

I could have choosen another way... like checking the size and if it's big enough open it with overwrite enabled and delete/recreate otherwise, but y'know there won't be any benefit doing so. Like there's a muffin with 100 bytes... and the new one is only 90... the remaining bytes would contain junk then (which could be annoying).

[Eventually that stuff is handled automatically, but I really can't be arsed to try that just for ending up with a more complex method which does the same]

So... just nuke it all and rebuild. Simple, pain free and relyable

>I take it the tags are the ones that I defined within the JNLP lib?

Yes, PersistenceService.TEMPORARY, PersistenceService.CACHED and PersistenceService.DIRTY. The javadoc comments will of course explain that

The unofficial jnlp faq said that those tags are only used by webstart to determine, in which order the muffins should be deleted if it runs out of space. First temp, then cache and then dirty. So if you want to keep em as long as possible (eg forever) then "dirty" would be the one you should pick.

>I'm really starting to like that style of using static
>methods on a class to get the collection, its really
>intuitive, at least for me

Yea, I thought it would be silly if you would have to create a dummy muffin just for getting the already stored muffins.

It would be like ordering random food in a restaurant for getting the bill of fare

---

What could be added is a getFileContents and a getRandomAcessFile method. Well, I won't have time to do any changes on that thing within the next 48 hours... I think I should have a pretty good idea then what's missing. Suggestions are of course still welcome.

Games published by our own members! Check 'em out!

[oNyx]

>Eventually that stuff is handled automatically

Most likely it is - there are two bytes (motorola byte order) at the beginning with the file length.

Eg a muffin with "lol" looks like this:

1   2

0003 6C6F 6C    3  l o  l

Well, I'll still keep that nuke and recreate approach since it's way simpler and I don't see any reason for doing that the other (more complicated) way.

[oNyx]

Known issues (demo app):
-MuffinTest.java:14 String muffinName is never used.
-load/savedelete throw a (non letal) NPE if the muffin directory doesn't exist (eg they work just fine if the directory is there but there aren't any muffins)

Just in case anyone stumbled upon that and wondered what went wrong there

edit: save of course doesn't throw an NPE

edit²

plan to add:
public String getText() readUTF()
public void setText(String text) writeUTF(String text)

I also had a somewhat closer look at overwriting and it isn't that complicated, but I still don't see a reason for doing so.

[kevglass]

I wonder if it would be ok if I borrowed this code and extended it to happily work in webstart or out?

Kev

[blahblahblahh]

We're going to stick it on JGF eventually anyway, so go ahead .

[oNyx]

I wonder if it would be ok if I borrowed this code and extended it to happily work in webstart or out?

My intention was to do something like that anyways... so what about teaming up?

Eg I could "finalize" the Muffin class, by adding these two methods and javadoc comments (and doing something about that demo app) and you could write the abstraction layer thingy and/or the file part and/or some design stuff.

1   2   3   4   5   6   7   8   9   10

public static String[] getNames() throws MuffinException public static String[] getNames(URL url) throws MuffinException //public boolean exists() throws MuffinException//eventually? public int getTag() throws MuffinException public void setTag(int tag) throws MuffinException public void delete() throws MuffinException public InputStream getInputStream() throws MuffinException public OutputStream getOutputStream() public String readUTF() public void writeUTF(String text)

Since there are two statics an interface won't do the trick.

[kevglass]

I reakon if we're to make it abstract then the two statics move to what ever manager/factory (MuffinOven? ) is used to create the muffins without knowing the implementation.

i.e.

1   2   3

String[] names = MuffingManager.getNames(); Muffin muffin = MuffinManager.getMuffin("mygame\mymuffin");

However, if we're to support a file system based version they're would have to be a way to hint at a location to store the muffins:

1	MuffinManager.setLocationHint("savedata");

which would be ignored by webstart version since thats the whole point

Ideas, ideas, ideas... what do you think?

Kev

[oNyx]

It's updated now.

The example now uses the new writeUTF() and readUTF() methods and that unneeded String is also gone. However, I wasn't able to do anything against those (non letal) NullPointerExceptions, because they are triggered under the hood of javaws :-/

Ah well... that's just a cosmetical thingy.

Btw javadoc comments are still missing.

---

And "hinting" the location... hmm... what are we gonna do if that one was omitted? Using a default directory? That only screams for trouble... or generating one by the change date in order to create a (basically) unique hex string, but that would mean that you loose your muffins once the jar was updated.

So... either enforce having such a directory name in each case and/or having one way for omitting it which won't work without webstart.

"MuffinOven" would be funny, yea... but we should try to avoid any confusion

Hm... getting that exists() working could be done by getting the names and checking for the specified one or by trying to open it's inputstream (but bouncing of exceptions feels pretty hacky).

Games published by our own members! Check 'em out!

[blahblahblahh]

"MuffinOven" would be funny, yea... but we should try to avoid any confusion

+1 for MuffinOven - these days, terms like "creator", "source", "manager", etc (and to a lesser extent the less variably used ones like "factory") are so over-used as to become meaningless. Heck, if Sun's going to make us call the damn things Muffins (groan) then it's a bit late to be trying to fight back by using standard names.

/me dons flame-retardant suit and hopes his words don't come back to haunt him sometime in the future when he's trying to use the API

[oNyx]

[...]
/me dons flame-retardant suit and hopes his words don't come back to haunt him sometime in the future when he's trying to use the API

Heh. Speaking of which... are the method names ok-ish?

I'm somewhat not that sure with readUTF and writeUTF, because they read/write always the whole thing. That's to be expected for readUTF, but it might be somewhat odd for the writeUTF(right?).

[kevglass]

While MuffinOven is pretty funny sticking to the conventional at least means that most people will understand what it is

readUTF and writeUTF just match up with DataInputStream/DataOutputStream so its kinda understood at least. Although I was surprised to see these methods added at all since you can get hold of the InputStream and OutputStream quite happily which of course you can wrap. I suppose as convienience goes its nice but its pretty unlikely I'd even be just writing a String into these files, at worst it'd be a properties file or XML. Although I suppose in turn you could create String froms them and dump those in.

The rest of naming is pretty darn good actually, couldn't ask for much more, apart from maybe Javadoc

Kev

[oNyx]

readUTF and writeUTF just match up with DataInputStream/DataOutputStream so its kinda understood at least. Although I was surprised to see these methods added at all since you can get hold of the InputStream and OutputStream quite happily which of course you can wrap. I suppose as convienience goes its nice but its pretty unlikely I'd even be just writing a String into these files, at worst it'd be a properties file or XML.

Yea, it's just... for very simple stuff. Sometimes you just need that, but... to tell the truth it's actually there for people who want to try it. Ooooh it really saves and loads that stuff... wow!

The rest of naming is pretty darn good actually, couldn't ask for much more, apart from maybe Javadoc

Kept it close to the common names for methods like these... and the javadoc... gonna do it. Should be there pretty soon now (tomorrow ).

[kevglass]

And "hinting" the location... hmm... what are we gonna do if that one was omitted? Using a default directory? That only screams for trouble... or generating one by the change date in order to create a (basically) unique hex string, but that would mean that you loose your muffins once the jar was updated.

So... either enforce having such a directory name in each case and/or having one way for omitting it which won't work without webstart.

I'm trying to do a version of this code at the moment and I'm still having a bit of trouble working out whats a valid use case for the standalone version.

1) Use it to test your code with
2) Use it to deploy a standalone version of your game

In the case of 1 I don't care where the muffins are put as long as its predictable. In the case of 2 I want the files to be in the same place everytime and somewhere that fits my install.

I'm still not quite sure how this can be achieved without something like a hint that is ignored in webstart mode?

Kev

[oNyx]

I think we can asume case #2 all the time, because it should be fine for #1, too.

And the "hint"... yes in webstart mode we should just ignore it. However, I would like having that thing a requirement (eg constructor-ish) even if it means that you have to enter some random crap or that the muffin alike thingys from non webstart mode just aren't available if omitted (eg throwing a runtime exception stating that you need to specify that directory).

Btw did you got an idea for detecting if it's started through webstart or not? I mean sure... there are some ways, but I still hadn't found something clean.

Btw² I'm writing the javadoc stuff right now

[kevglass]

This is what I've done so far, its not pretty:

1   2   3   4   5   6   7   8   9   10   11

webstart = true;              try {      Class.forName("javax.jnlp.ServiceManager");                         // this causes to go and see if the service is available     ServiceManager.lookup("javax.jnlp.PersistenceService"); } catch (Exception e) {      System.err.println("MuffinProvider: No webstart detected");      webstart = false; }

Kev

[oNyx]

Well, that will do it for now (forever?)

[kevglass]

Onyx, is there somewhere I can mail you my version of the code so far so you can take a look. I don't want to just post it publically here and just override the existing stuff until we're both happy with it.

Kev

[oNyx]

Ah... uhm... sure

kunnichiwa <thatthing> gmx <thatdot> de

[oNyx]

>Eventually that stuff is handled automatically

Most likely it is - there are two bytes (motorola byte order) at the beginning with the file length.

Eg a muffin with "lol" looks like this:

1   2

0003 6C6F 6C    3  l o  l

Well, I'll still keep that nuke and recreate approach since it's way simpler and I don't see any reason for doing that the other (more complicated) way.

/me is silly

Those two bytes are the length information written by DataOutputStream's writeUTF()

However, I have a little problem with two methods...

getText()/readUTF()
setText(String text)/writeUTF(String text)

The former sounds (by convention) somewhat "displayable" and the latter leads to the asumption that there is also the other stuff, which you can find in DataIn/Outputstream like writeShort etc.

Way too much confusion for two "demoing" methods... so... hmm... how about:

writePlainText(String text)
readPlainText()

or something like that?!

---

Something came up which screwed my schedule a bit, but the javadoc stuff is almost done now... I just need to read over it once again (I think).

[kevglass]

Plain text sounds good. Simpler.

Kev

[oNyx]

Just mailed you that javadoced source btw

And plain text is it then? Ok

I'll add/change that later (need food/sleep )

[oNyx]

That silly NPE is gone. I accidently copied that www jnlp file over my local jnlp file at the time I tried to do something against that. Silly me

An NPE is thrown if the directoy doesn't exist... so getNames should return an empty String array then (like it does if the directoy exists but doesnt contain any muffins).

[oNyx]

http://kaioa.com/src/tools/MuffinTest4c.jnlp
http://kaioa.com/src/tools/MuffinTest4c.jar

That's the new test thingy. It should work in both cases - webstarted and lauchned locally.

The used directory in non-webstart mode is:
"user.dir"+"/Muffin Test4c/"

Source code follows after cleanup/commenting. Well, for now we need some testing

---

Kev, you got mail

[oNyx]

Dear diary...

Well, ok I thought it would be nice to write something about the current status of this little project.

Right now there are 6 klasses (5 public 1 inner) and their size is about 8kb (jared).

It's now basically done and works pretty well. Using it is also really painless (as intended).

Javadoc-wise I'm also halfway through, but I noticed (while writing the docs) that I forget to test if using pathes works correctly. However, it will be done pretty soon now

[Malohkan]

How's this coming?  I'd love to use the API in Rimscape as I've come to the point where I want to implement its usage... like... today  Can I expect javadocs soon or a source release?  Anything so I know how to use your creation?  I'd also appreciate a "not soon" if that's the case so I can go out and learn to do this myself if I have to.  Thanks!

[oNyx]

Kev had some problems with it and I was so far unable to track the cause down, because it always worked fine for me. Things like webstart throwing the muffin away on exit or being unable to delete the muffin :-/

I'm a bit puzzled since the demo application worked flawlessly on a broad range of different configurations and operating systems.

Well, you can of course toy around with last moth's source:
http://kaioa.com/src/tools/MuffinTest4c_src.zip

If it works - great and if it doesn't... maybe you can track down the reason. Either way let us know

[Malohkan]

I'll do my best and let you know what I find!  Thanks

[Malohkan]

I have just one more question.



Do you know the Muffin Man?