Re: [hpoj-devel] some port of PML to ptal

[Jarl F. <ja...@di...>]

On Sun, 31 Dec 2000, David Paschal wrote:

> Jarl Friis wrote:
> > I have ported some of the PML stuff to the ptal API.
> > 
> > until now I have ported getValue and setvalue, they are not thoroughly
> > tested, but I can get the LCD lines at least :-) porting xojpanel..???
> Hi, Jarl.  I've actually done a lot of this work already (adding PML
> support to PTAL).  I'm using a different design from ojlib, so I started
> from scratch rather than porting ojlib code, just as I did with PTAL itself.

I thought when there is no sign of this in the cvs, it was a
job to be done, anyway I got a deep knowledge of MLC, PML, so I will
eventually be able contribute on something else.

But I still wonder why the CVS is on the release-0.7 stage... is it only
used for realeases? not development?

> > I do not have the time to continue the development in January, but I might
> > do something in February, hope the code is good for soemthing, at least
> > inspiration :-)
> I got distracted from this lately dealing with I/O and printing issues in
> preparation for releasing 0.7, and I'll try to get back to it within the
> next couple of weeks.

Are you working full-time on hpoj?

> 
> > 2)How are the THREE bytes of errorcode (after the exec_code byte) supposed
> > to be interpreted when such are sent as a reply?
> According to the PML spec (which you can get by registering for a free
> membership at http://www.hp-developer-solutions.com), these three bytes are:

Thanks, that helped a lot.

> > I am currently working on adding the PML to the ptal, and I discovered
> > that the PML oids on the web are not the same as in the
> > ojlib/pmloidentries.c the difference are (at least) the two folloing
> > objects:
> I plan to significantly rewrite the web-based documentation once I finish
> obsoleting ojlib and (if everything goes well) ieee12844*.c.  In addition,
> I want to avoid coding knowledge of specific OIDs at the PTAL level, so
> the centralized OID table will either go away or move somewhere else in
> the codebase.

Good idea, the OID tables are device dependent, different devices
recongnise different OIDs, correct?, so there should probably be one
OID-table for each device or devicegroup, it would be smart if one could
autodetect what kind of device, and then use the related table for that,
the one on the web/in the pmloidentries.c is for OfficeJets I guess.

Jarl