On Mon, 25 Feb 2002, Nick May wrote:
> (Not that there is anything wrong
> with 6502 machine code. Ee! - when I were a lad....).
Err...well...if you really go for a RISC CPU with only one register....
(I count X and Y as memory, since it wasn't until much later--and
much less common--versions of the CPU that you could do direct
loads and stores between them and memory.)
And let's not forget that lovely little bug where if your branch
address is split across a (256-byte) page boundry, it loads the
second byte from location 0 in the current page, rather than in
the next. Whee.
> > Data can have inaccuracies, but not bugs or features. So of
> >course it's just consumed, and not contributed to.
>
> I don't think this follows.
I'm siding with Nick here. If you find a mistake in the data, why
would you not submit a correction? Unless you're the sort who loves
to merge your private patches every time you update, just for the
fun of battling with CVS.
> I suspect that
> if the contributors to this discussion had collectively spent as much time
> hacking as we have in discussion, we would have a semi-workable framework
> already.
Absolutely! Less talk, more code!
Keep in mind that if you get the code wrong, you can always change
it. The resistance to massive change is normally directly proportional
to the number of users your system has and the length of time of
the system's existence. Since both of these coefficients are
currently zero....
Also, when you're looking at a system used only by other programmers,
who almost always have full source for what they're working on,
API changes just aren't that painful. Your customers rewrite, or
they don't upgrade if they don't want to rewrite. It's no big deal.
> Granted, it is all more complex in a cocoon type environment, and much
> thought should be given to datastructure....
I really don't think you need to bother. The XML part is fairly
simple; you have a bunch of attributes with names and values. From
this you create objects with getter and setter method. Now come up
with some reasonable way of representing the parts of the User-agent
header you want to parse, and write a lookup method that takes a
User-agent line and returns an appropriate object with the data
for that phone. You're now done with the data representation
portion.
You've still got a pile of work to do in terms of moving from having
a pile of data about a phone to being able to efficiently construct
a web page customized for the phone, but that's something that is
a) going to require a lot of experimentation, and b) will probably
differ somewhat from application to application, anyway.
> Can we stop philosophizing about it and just get on with it?
Yes, let's.
Step 1: come up with a list of attributes of phones. Screen size
in pixels and chars, colour vs. b/w, the obvious ones. Don't spend
more than five minutes on this, because you can come back again
later.
Step 2: write a sample XML file encoding these data for a half
dozen popular phones.
Step 3: with this file in hand, write the XML stylesheet explaining
how to interpret this file.
Step 4: Create a Java object with getter methods for these data fields.
Step 5: Create a Java object that, given the XML file, acts as a
factory for these objects. But first write the unit tests for it.
Step 6: You now have something useful, and a program you can run
to prove that it works. Figure out what's missing, and add it.
Repeat.
cjs
--
Curt Sampson <cjs_at_cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
Received on Mon Feb 25 17:21:17 2002