||[Dec. 13th, 2001|07:35 pm]
LiveJournal Client Discussions
Okay, back in July when I was starting to work on Clive I was given an URL to see what properties there were for the prop_name entry in the postevent mode. First off, how would I go about updating the postevent mode documention so that it reflects the existance of the URL Evan gave me in this thread?|
Second question, if you go and look at it, it shows that the property IDs go 1, 2, 8, 4, 5, 6, 7...is that on purpose? Where did 3 go? Why is 8 where 3 would've been? I don't know if the tableview pulls the data straight from the table or if it precompiles...or if it is handmade and doesn't pull data from the database at all. In any case, is there any importance to those IDs as far as using the properties? Do I put
Next, what is the significance of passing back the current_moodid if I pass back current_mood? I would presume that if I pass back a mood without the moodid, then the mood is printed but no icons are placed. Is that correct?
Lastly, to do userpic stuff we pass back the *label* of the userpic? As in when we do the login we retrieve the list of names, then send back one of those names (or nothing if we want the default), right?
Thanks a bundle
2001-12-13 06:55 pm (UTC)
a) Send in a patch?
the id is just for the database.
The tableview pulls the data from the database. What kind of animals do you think we are? We don't have time to make pretty tables by hand... :P
c) Yeah, think so. I personally think moodid should die on the client end, but it needs to be implemented.
d) Yeah, the label. The nice thing about writing stuff in Perl is that doing stuff in strings isn't any more difficult than doing everything with ID numbers, and using strings makes the protocol a bit simpler. ;)
a) I will admit ignorance and some degree of laziness. I suspect I need a goathack account in order to submit a patch (as I read a post about that a couple days ago)...but how do I get a goathack account? *grin* I found an old post in the goathack journal that says to ask dormando, is that what I still need to do?
b) Then why does it go 1, 2, 8, 4, 5, 6, 7? :P did 3 vanish into oblivion (eg a property was deleted)?
c) So if I don't implement moodid my moods will all show up sans-icon...gotcha. Hence the need to download the moodlist at all.
d) Yeah, and its only marginally more difficult to do the same thing in C, which is what I'm using. Can I be assured of any particular order in the list I get back from the login?
2001-12-13 08:23 pm (UTC)
a) Yeah, ask dormando.
b) No idea.
d) I think it comes back in alphabetical order, but don't depend on it.
FWIW, LogJam just displays them in the order it receives them.
For the time being Clive is strictly command line. The limit on interactivity is opening up VI to edit things like the logtext itself. I'm planning on passing in things like the mood and the userpic via command line options as in:
$ clive --userpic itouchhere --mood accomplished
So I want to validate the userpic against the list I receive when I log in. Since I'm not using hashes (since I'm in C, and don't feel motivated to bloat my code by doing hashes). I'll just plop them in a char** array and I'll probably end up sorting them. I may be motivated enough to put them in a simple binary tree. Would likely do that with moods at least.
Unless, of course, the protocol automatically ignores incorrect userpic IDs...does it?
2001-12-18 06:58 am (UTC)
It's perfectly valid to send a pic keyword which doesn't (at this time) point at a picture. Later on it might start pointing at a picture, at which point it'll start displaying that picture.
In your case, then, I'd say it's perfectly okay for you to not validate the userpic keyword at all. The list returned by the login protocol mode is mostly for the benefit of the user interface.
*nodnod* My end decision was to add some sort of option to print out a list, give each keyword a number, and then allow either a number or a word to be passed in. Since it's easier to type in